Re: pg_auth_members.grantor is bunk

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_auth_members.grantor is bunk
Date: 2022-06-24 20:29:47
Message-ID: CAKFQuwar8xU2H0eHhJ00-GYT56V3nRwFKJ_bLHD0H-JU3PYaQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 24, 2022 at 1:19 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Jun 6, 2022 at 7:41 PM Stephen Frost <sfrost(at)snowman(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-06-24 20:46:42 Re: pg_auth_members.grantor is bunk
Previous Message Justin Pryzby 2022-06-24 20:28:24 Re: pg_upgrade (12->14) fails on aggregate