> On Jul 23, 2021, at 2:04 PM, Mark Dilger <mark.dil...@enterprisedb.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
