Re: role self-revocation

On Mon, Mar 7, 2022 at 11:18 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, Mar 6, 2022 at 11:01 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > The example, which you moved here, then attempts to demonstrate this
> "fact" but gets it wrong. Boss became a member of peon so if you want to
> demonstrate self-administration of a role's membership in a different group
> you have to login as boss, not peon. Doing that, and then revoking peon
> from boss, yields "ERROR: must have admin option on role "peon"".
>
> This doesn't seem to me to be making a constructive argument. I showed
> an example with certain names demonstrating a certain behavior that I
> find problematic.

Whether you choose the wording of the original thread:

"This is because we allow 'self administration' of roles, meaning that
they can decide what other roles they are a member of."

https://www.postgresql.org/message-id/flat/20211005025746.GN20998%40tamriel.snowman.net

Or you quote at the top of this one:

> The ability of a role to revoke itself from some other role is just
> something we need to accept as being a change that needs to be made,

This example:

rhaas=# create user boss;
CREATE ROLE
rhaas=# create user peon;
CREATE ROLE
rhaas=# grant peon to boss;
GRANT ROLE
rhaas=# \c - peon
You are now connected to database "rhaas" as user "peon".
rhaas=> revoke peon from boss; -- i don't like being bossed around!
REVOKE ROLE

Fails to demonstrate the boss "can revoke itself from peon" / "boss can
decide what other roles they are a member of."

You are logged in as peon when you do the revoke, not boss, so the extent
of what "boss" can or cannot do has not been shown.

boss is a member of peon, not the other way around. That the wording
"grant peon to boss" makes you think otherwise is unfortunate.

David J.