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 по дате отправления: