Re: Granting control of SUSET gucs to non-superusers

Greetings,

* Jacob Champion (pchampion(at)vmware(dot)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?

The question is about exactly what the operation is, not about what that
operation might allow someone to be able to do by using that access.

'network' might, in theory, allow someone to connect out on a port that
happens to have a bash shell that's running as root on the local box too
which means that it "could" be used to gain 'host' access but that's not
really our concern.

To that point, if it's allowing access to run programs on the host then
'host' is required, but I don't think we should also require 'network'
for 'run programs on the host' because someone might run 'curl' with
that access- that's an issue for the admin and the curl utility to
figure out.

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

We've been working in that direction for a long time. :)

Thanks,

Stephen