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

> On Jul 23, 2021, at 2:04 PM, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
> If the GUC merely converts the event trigger into an error, then you have the problem that the customer can create event triggers which the service provider will need to disable (because they cause the service providers legitimate actions to error rather than succeed).

I'd like to expound on this a little more.

Imagine the service provider has scripts that perform actions within the database, such as physical replication, or the creation and removal of database users in response to actions taken at the service portal web interface, and they don't want the actions performed by those scripts to be leveraged by the customer to break out of the jail.

The customer has event triggers which perform no illicit activities. They don't try to break out of the jail. But for compliance with HIPAA regulations (or whatever), they need to audit log everything, and they can't just have the service provider's actions unlogged.

What to do? If the service provider disables the event triggers, then the customer will fail their regulation audit. If the service provider allows the event triggers to fire, the customer might create a new event trigger embedding illicit actions. The service provider is totally stuck.

OTOH, if there were a mechanism by which an event trigger could run with only the intersection of the privileges enjoyed by the service provider's scripts and the customer's event trigger owner, then the service provider can allow their own actions to be logged, without fear that any hijacking of their privilege will occur.

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