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

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Jacob Champion <pchampion(at)vmware(dot)com>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "chap(at)anastigmatix(dot)net" <chap(at)anastigmatix(dot)net>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Date: 2021-07-06 16:38:01
Message-ID: BF739C25-293C-4146-AD01-6C959A459EAB@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jul 5, 2021, at 1:50 AM, Andrey Borodin <x4mmm(at)yandex-team(dot)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 SYSTEM SET to three roles: pg_database_security, pg_network_security, and pg_host_security. I don't mind expanding this list to include the replication attribute, but I am curious about opinions on the general design. There may be an advantage in keeping the list short. In particular, as the list gets longer, will it get harder to decide which role to associate with each new GUC that gets added? For third-party extensions, will it be harder for them to decide in any principled way which role to assign to each GUC that they add? There are multiple ways to cut up the set of all GUCs. database/host/network is not an entirely clean distinction, and perhaps database/host/network/replication is better, but I'm uncertain.


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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-07-06 16:51:54 Re: Grammar railroad diagram
Previous Message Tom Lane 2021-07-06 16:37:38 Re: logical replication worker accesses catalogs in error context callback