Hi,
On Wed, Mar 12, 2025 at 9:06 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> I think this approach has other problems. For example, even if a role has
> admin directly on the dropped role, we'll block DROP ROLE if it also has
> admin indirectly:
>
This is exactly what we're aiming for. We don't want the ADMIN
privilege, inherited by role 'a' on role 'c' via role 'b', to be
removed by the drop command. Therefore, we expect the command to fail.
> There are also other ways besides DROP ROLE that roles can end up without
> any admins:
>
> postgres=# create role a createrole;
> CREATE ROLE
> postgres=# set role a;
> SET
> postgres=> create role b createrole;
> CREATE ROLE
> postgres=> set role b;
> SET
> postgres=> create role c;
> CREATE ROLE
> postgres=> reset role;
> RESET
> postgres=# revoke c from b;
> REVOKE ROLE
>
> I wonder if we should adjust the requirements here to be "an operation
> cannot result in a role with 0 admins." That does mean you might lose
> indirect admin privileges, but I'm not sure that's sustainable, anyway.
> For example, if a role has 2 admins, should we block REVOKE from one of the
> admins because another role inherited its privileges? If nothing else, it
> sounds like a complicated user experience.
>
I think this is acceptable because role 'b', from which role 'a'
inherited the ADMIN privilege on role 'c', no longer has the privilege
either. Therefore, it's understandable for role 'a' to lose the
indirect privilege, as the role it was inheriting from has also lost
it. Moreover, this action is being performed by a superuser, the same
superuser who granted the ADMIN privilege on role 'c' to role 'b', and
it should have the ability to revoke it at any time. Once role 'b'
loses the ADMIN privilege on role 'c', it's expected that role 'a'
will also lose the privilege, as it was inherited from role 'b'. After
the ADMIN privilege is revoked, role 'a' will no longer have a
dependency on role 'b', so dropping role 'b' should succeed.
--
With Regards,
Ashutosh Sharma.
