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

From David G. Johnston
Subject Re: pg_auth_members.grantor is bunk
Date
Msg-id CAKFQuwar8xU2H0eHhJ00-GYT56V3nRwFKJ_bLHD0H-JU3PYaQw@mail.gmail.com
Whole thread Raw
In response to Re: pg_auth_members.grantor is bunk  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_auth_members.grantor is bunk  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Jun 24, 2022 at 1:19 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jun 6, 2022 at 7:41 PM Stephen Frost <sfrost@snowman.net> wrote:
>
> In terms of how that's then used, yeah, it's during REVOKE because a
> REVOKE is only able to 'find' role authorization descriptors which match
> the triple of role revoked, grantee, grantor (though there's a caveat in
> that the 'grantor' role could be the current role, or the current user).

What is supposed to happen if someone tries to execute DROP ROLE on a
role that has previously been used as a grantor?

Upthread, I proposed that "drop role baz" should fail here

I concur with this.

I think that the grantor owns the grant, and that REASSIGNED OWNED should be able to move those grants to someone else.

By extension, DROP OWNED should remove them.

David J.

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: pg_upgrade (12->14) fails on aggregate
Next
From: Robert Haas
Date:
Subject: Re: pg_auth_members.grantor is bunk