Re: allowing for control over SET ROLE

Поиск
Список
Период
Сортировка
От Wolfgang Walther
Тема Re: allowing for control over SET ROLE
Дата
Msg-id fbdc7ddc-c48c-f660-81ba-0553c53c83fc@technowledgy.de
обсуждение исходный текст
Ответ на allowing for control over SET ROLE  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: allowing for control over SET ROLE  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas:
> Beginning in
> e3ce2de09d814f8770b2e3b3c152b7671bcdb83f, the inheritance behavior of
> role-grants can be overridden for individual grants, so that some
> grants are inherited and others are not.

That's a great thing to have!

> However, there is no similar
> facility for controlling whether a role can SET ROLE to some other
> role of which it is a member. At present, if role A is a member of
> role B, then A can SET ROLE B, and that's it.
> 
> In some circumstances, it may be desirable to control this behavior.

+1

> rhaas=# grant oncall to oncallbot with inherit false, set false, admin true;

Looking at the syntax here, I'm not sure whether adding more WITH 
options is the best way to do this. From a user perspective WITH SET 
TRUE looks more like a privilege granted on how to use this database 
object (role). Something like this would be more consistent with the 
other GRANT variants:

GRANT SET ON ROLE oncall TO oncallbot WITH GRANT OPTION;

This is obviously not exactly the same as the command above, because 
oncallbot would be able to use SET ROLE directly. But as discussed, this 
is more cosmetic anyway, because they could GRANT it to themselves.

The full syntax could look like this:

GRANT { INHERIT | SET | ALL [ PRIVILEGES ] }
   ON ROLE role_name [, ...]
   TO role_specification [, ...] WITH GRANT OPTION
   [ GRANTED BY role_specification ]

With this new syntax, the existing

GRANT role_name TO role_specification [WITH ADMIN OPTION];

would be the same as

GRANT ALL ON role_name TO role_specification [WITH GRANT OPTION];

This would slightly change the way INHERIT works: As a privilege, it 
would not override the member's role INHERIT attribute, but would 
control whether that attribute is applied. This means:

- INHERIT attribute + INHERIT granted -> inheritance (same)
- INHERIT attribute + INHERIT not granted -> no inheritance (different!)
- NOINHERIT attribute  + INHERIT not granted -> no inheritance (same)
- NOINHERIT attribute  + INHERIT granted -> no inheritance (different!)

This would allow us to do the following:

GRANT INHERIT ON ROLE pg_read_all_settings TO seer_bot WITH GRANT OPTION;

seer_bot would now be able to GRANT pg_read_all_settings to other users, 
too - but without the ability to use or grant SET ROLE to anyone. As 
long as seer_bot has the NOINHERIT attribute set, they wouldn't use that 
privilege, though - which might be desired for the bot.

Similary, it would be possible for the oncallbot in the example above to 
be able to grant SET ROLE only - and not INHERIT.

I realize that there has been a lot of discussion about roles and 
privileges in the past year. I have tried to follow those discussions, 
but it's likely that I missed some good arguments against my proposal above.

Best

Wolfgang



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

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: [RFC] building postgres with meson - v12
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Add the ability to limit the amount of memory that can be allocated to backends.