Re: replacing role-level NOINHERIT with a grant-level option
От | Robert Haas |
---|---|
Тема | Re: replacing role-level NOINHERIT with a grant-level option |
Дата | |
Msg-id | CA+TgmobLsD4JOEBZNMb9hYyr3MN6b8tb4LTY=PnmZ+7S5dj6mQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: replacing role-level NOINHERIT with a grant-level option (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: replacing role-level NOINHERIT with a grant-level option
|
Список | pgsql-hackers |
On Thu, Jun 2, 2022 at 2:07 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > I think we should also consider replacing role attributes with predefined > roles. I'm not sure that this proposal totally prepares us for such a > change, given role attributes apply only to the specific role for which > they are set and aren't inherited. ISTM in order to support that, we'd > need even more enhanced functionality. For example, if I want 'robert' to > be a superuser, and I want 'joe' to inherit the privileges of 'robert' but > not 'pg_superuser', you'd need some way to specify inheriting only certain > privileges possessed by an intermediate role. I guess we could think about adding something like an ONLY clause, like GRANT ONLY robert TO joe. I feel a little bit uncomfortable about that, though, because it assumes that robert is a superuser but his own privileges are distinguishable from those of the superuser. Are they really? If I can assume robert's identity, I can presumably Trojan my way into the superuser account pretty easily. I'll just define a little trigger on one of his tables. I don't really see a way where we can ever make it safe to grant a non-superuser membership in a superuser role. But even if there is a way, I think that is a separate patch from what I'm proposing here. [NO]INHERIT only has to do with what privileges you can exercise without SET ROLE. To solve the problem you're talking about here, you'd need a way to control what privileges are conferred in any manner, which is related, but different. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: