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

> On Jul 23, 2021, at 1:57 PM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
> What's the point in having these as separate roles if they can circumvent each other's authority?

That was probably too brief a reply, so let me try again.  If the GUC circumvents the event trigger, then my answer
abovestands.  If the GUC merely converts the event trigger into an error, then you have the problem that the customer
cancreate event triggers which the service provider will need to disable (because they cause the service providers
legitimateactions to error rather than succeed).  Presumably the service provider can disable them logged in as
superuser. But that means the service customer has their event trigger turned off, at least for some length of time,
whichis not good if the event trigger is performing audit logging for compliance purposes, etc.  Also, we can't say
whetherpg_network_security role has been given to the customer, or if that is being kept for the provider's use only,
sowe're not really sure whether pg_network_security should be able to do these sorts of things, but in the case that
theservice provider is keeping pg_network_security for themself, it seems they wouldn't want the customer to cause
pg_network_securityoperations to fail.  We can't make too many assumptions about the exact relationship between those
tworoles. 



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