Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Date
Msg-id BBBC16D5-69EC-4220-B8AA-5AF7E11FCC89@amazon.com
Whole thread Raw
In response to Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 10/4/21, 7:08 PM, "Stephen Frost" <sfrost@snowman.net> wrote:
> I really think we need to stop addressing roles explicitly as
> 'superuser' vs. 'non-superuser', because a non-superuser role can be
> GRANT'd a superuser role, which makes that distinction really not
> sensible.  This has continued to be a problem and we need to cleanly
> address it.  Not sure exactly how to do that today but it's certainly an
> issue.

Agreed.  Maybe one option is to convert most of the role attributes to
be predefined roles.  Then we could just check for membership in
pg_superuser instead of trying to deal with membership in roles that
have the SUPERUSER attribute.

Nathan


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Make relfile tombstone files conditional on WAL level
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #17212: pg_amcheck fails on checking temporary relations