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

Поиск
Список
Период
Сортировка

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: 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)