Re: Granting control of SUSET gucs to non-superusers - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Granting control of SUSET gucs to non-superusers
Date
Msg-id 941B8A0F-CF69-471A-A88C-7CFD2705EEEC@enterprisedb.com
Whole thread Raw
In response to Re: Granting control of SUSET gucs to non-superusers  (Jacob Champion <pchampion@vmware.com>)
Responses 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 May 13, 2021, at 12:18 PM, Jacob Champion <pchampion@vmware.com> wrote:
>
> On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
>> The distinction that Theme+Security would make is that capabilities
>> can be categorized by the area of the system:
>>  -- planner
>>  -- replication
>>  -- logging
>>  ...
>> but also by the security implications of what is being done:
>>  -- host
>>  -- schema
>>  -- network
> Since the "security" buckets are being used for both proposals -- how
> you would deal with overlap between them? When a GUC gives you enough
> host access to bleed into the schema and network domains, does it get
> all three attributes assigned to it, and thus require membership in all
> three roles?

Yeah, from a security standpoint, pg_host_admin basically gives everything away.  I doubt service providers would give
the"host" or "network" security to their tenants, but they would probably consider giving "schema" security to the
tenants.

> (Thanks, by the way, for this thread -- I think a "capability system"
> for superuser access is a great idea.)

I am happy to work on this, and appreciate feedback....

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






pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Granting control of SUSET gucs to non-superusers
Next
From: Robert Haas
Date:
Subject: Re: amvalidate(): cache lookup failed for operator class 123