Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
От | Mark Dilger |
---|---|
Тема | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |
Дата | |
Msg-id | BF739C25-293C-4146-AD01-6C959A459EAB@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) (Andrey Borodin <x4mmm@yandex-team.ru>) |
Список | 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 по дате отправления: