Re: role self-revocation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: role self-revocation
Дата
Msg-id CA+TgmoYPkX4t7GhEuONJO+0eerHoMDvNJ75DfQVeFd2W1Le1xQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: role self-revocation  (Joshua Brindle <joshua.brindle@crunchydata.com>)
Список pgsql-hackers
On Thu, Mar 10, 2022 at 12:26 PM Joshua Brindle
<joshua.brindle@crunchydata.com> wrote:
> Ownership implies DAC, the ability to grant others rights to an
> object. It's not "kooky" to see roles as owned objects, but it isn't
> required either. For example most objects on a UNIX system are owned
> and subject to DAC but users aren't.

I have no issue with anything you write in this paragraph.

> Stephen's, and now my, issue with ownership is that, since it implies
> DAC, most checks will be bypassed for the owner. We would both prefer
> for everyone to be subject to the grants, including whoever created
> the role.

That sounds like MAC, which is usually something that sits on top of
DAC and is enforced in addition to DAC, not a reason for DAC to not
exist.

> Rather, we'd like to see a "creators of roles get this set of grants
> against the role by default" and "as a superuser I can revoke grants
> from creators against roles they created"

If you create a table, you own it. You get a set of default
permissions on the table which can be revoked either by you or by
someone else, and you also have certain intrinsic rights over the
object as owner which cannot be revoked - including the ability to
re-grant yourself any previously-revoked permissions. I am not against
the idea of trying to clean things up so that everything you can do
with a table is a revocable privilege and you can be the owner without
having any rights at all, including the right to give yourself other
rights back, but I cannot believe that the idea of removing table
ownership as a concept would ever gain consensus on this list.
Therefore, I also do not think it is reasonable to say that we
shouldn't introduce a similar concept for object types that don't have
it yet, such as roles.

But that's not to say that we couldn't decide to do something else
instead, and that other thing might well be better. Do you want to
sketch out a full proposal, even just what the syntax would look like,
and share that here? And if you could explain how I could use it to
create the mini-superusers that I'm trying to get out of this thing,
even better.

Thanks,

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: role self-revocation
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Column Filtering in Logical Replication