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

From Mark Dilger
Subject Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Date
Msg-id BF739C25-293C-4146-AD01-6C959A459EAB@enterprisedb.com
Whole thread Raw
In response to Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers

> On Jul 5, 2021, at 1:50 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> I'm not sure, but maybe we should allow replication role to change session_replication_role?

Thanks, Andrey, for taking a look.

Yes, there is certainly some logic to that suggestion.  The patch v4-0005 only delegates authority to perform ALTER
SYSTEMSET to three roles:  pg_database_security, pg_network_security, and pg_host_security.  I don't mind expanding
thislist to include the replication attribute, but I am curious about opinions on the general design.  There may be an
advantagein keeping the list short.  In particular, as the list gets longer, will it get harder to decide which role to
associatewith each new GUC that gets added?  For third-party extensions, will it be harder for them to decide in any
principledway which role to assign to each GUC that they add?  There are multiple ways to cut up the set of all GUCs.
database/host/networkis not an entirely clean distinction, and perhaps database/host/network/replication is better, but
I'muncertain.  

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: logical replication worker accesses catalogs in error context callback
Next
From: Bruce Momjian
Date:
Subject: Re: Grammar railroad diagram