Re: pg_auth_members.grantor is bunk

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: pg_auth_members.grantor is bunk
Дата
Msg-id 79b225aa7d721b31fbe0fe518f434f9bb16a6c12.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: pg_auth_members.grantor is bunk  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On Tue, 2022-09-06 at 16:26 -0700, Jeff Davis wrote:
> In other words, omitting
> GRANTED BY is the same as specifying "GRANTED BY current_user".

Let me correct this thinko to distinguish between specifying GRANTED BY
and not:

  * Let the granting user be the one specified in the GRANTED BY clause
if it exists; otherwise the current user.
  * If the granting user has privileges to be the grantor (ADMIN OPTION
for roles, GRANT OPTION for other objects) then the granting user is
the grantor.
  * Else if GRANTED BY was *not* specified, infer the grantor:
    - If the granting user inherits from a role with the privileges
to be the grantor, then it selects a role with the fewest inheritance
hops as the grantor.
    - Else if the current user is any superuser, the grantor is the top
"owner" (bootstrap superuser for roles; object owner for other objects)
  * Else error (or if an error would break important backwards
compatibility, silently make it work like before and perhaps issue a
WARNING).

The basic idea is to use superuser privileges as a last resort in order
to maximize the cases that work normally (independent of superuser-
ness).

Regards,
    Jeff Davis




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

Предыдущее
От: Reid Thompson
Дата:
Сообщение: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: PostgreSQL 15 Beta 4 release announcement draft