Re: role self-revocation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: role self-revocation
Date
Msg-id 3022490.1648141826@sss.pgh.pa.us
Whole thread Raw
In response to Re: role self-revocation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: role self-revocation  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Notwithstanding the lack of agreement on that point, I believe that
> what we should do for v15 is remove the session user
> self-administration exception. We have pretty much established that it
> was originally introduced in error.

Agreed.

> However, it might. And if it does, I think it would be best if
> removing that exception were the *only* change in this area made by
> that release.

Good idea, especially since it's getting to be too late to consider
anything more invasive anyway.

> So I propose to commit something like what I posted here:
> http://postgr.es/m/CA+TgmobgeK0JraOwQVPqhSXcfBdFitXSomoebHMMMhmJ4gLonw@mail.gmail.com

+1, although the comments might need some more work.  In particular,
I'm not sure that this bit is well stated:

+     * A role cannot have WITH ADMIN OPTION on itself, because that would
+     * imply a membership loop.

We already do consider a role to be a member of itself:

regression=# create role r;
CREATE ROLE
regression=# grant r to r;
ERROR:  role "r" is a member of role "r"
regression=# grant r to r with admin option;
ERROR:  role "r" is a member of role "r"

It might be better to just say "By policy, a role cannot have WITH ADMIN
OPTION on itself".  But if you want to write a defense of that policy,
this isn't a very good one.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: turn fastgetattr and heap_getattr to inline functions
Next
From: Robert Haas
Date:
Subject: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations