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(dot)dilger(at)enterprisedb(dot)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 above stands. 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). 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, which is not good if the event trigger is performing audit logging for compliance purposes, etc. Also, we can't say whether pg_network_security role has been given to the customer, or if that is being kept for the provider's use only, so we're not really sure whether pg_network_security should be able to do these sorts of things, but in the case that the service provider is keeping pg_network_security for themself, it seems they wouldn't want the customer to cause pg_network_security operations to fail. We can't make too many assumptions about the exact relationship between those two roles.

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