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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: logical replication worker accesses catalogs in error context callback
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Grammar railroad diagram