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

From Mark Dilger
Subject Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Date
Msg-id B197F337-3BD1-4B9D-8829-A5A58EF7C1FF@enterprisedb.com
Whole thread Raw
In response to Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers

> 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






pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Next
From: Tom Lane
Date:
Subject: Removing "long int"-related limit on hash table sizes