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.dilger@enterprisedb.com> wrote:
>
> If the GUC merely converts the event trigger into an error, then you have the problem that the customer can create
eventtriggers which the service provider will need to disable (because they cause the service providers legitimate
actionsto 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
creationand removal of database users in response to actions taken at the service portal web interface, and they don't
wantthe 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
compliancewith HIPAA regulations (or whatever), they need to audit log everything, and they can't just have the service
provider'sactions unlogged. 

What to do?  If the service provider disables the event triggers, then the customer will fail their regulation audit.
Ifthe service provider allows the event triggers to fire, the customer might create a new event trigger embedding
illicitactions.  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
enjoyedby the service provider's scripts and the customer's event trigger owner, then the service provider can allow
theirown 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