Re: pg_auth_members.grantor is bunk - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: pg_auth_members.grantor is bunk
Date
Msg-id 79b225aa7d721b31fbe0fe518f434f9bb16a6c12.camel@j-davis.com
Whole thread Raw
In response to Re: pg_auth_members.grantor is bunk  (Jeff Davis <pgsql@j-davis.com>)
List 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 by date:

Previous
From: Reid Thompson
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.
Next
From: "Jonathan S. Katz"
Date:
Subject: PostgreSQL 15 Beta 4 release announcement draft