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 | F8FADE5E-CB9A-40BE-949B-61B981613064@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |
Список | pgsql-hackers |
> On Jul 23, 2021, at 1:54 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > Yeah, but you're inventing a system for allowing the restriction on a > GUC to be something other than is-superuser in the very patch we're > talking about. So it could be something like is-database-security. > Therefore I don't grok the objection. I'm not objecting to how hard it would be to implement. I'm objecting to the semantics. If the only non-superuser who canset the GUC is pg_database_security, then it is absolutely worthless in preventing pg_database_security from trappingactions performed by pg_network_security members. On the other hand, if pg_network_security can also set the GUC,then pg_network_security can circumvent audit logging that pg_database_security put in place. What's the point in havingthese as separate roles if they can circumvent each other's authority? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: