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

Greetings,

* Mark Dilger (mark(dot)dilger(at)enterprisedb(dot)com) wrote:
> > On Aug 23, 2021, at 12:51 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Simply using superuser_arg() isn't sufficient is exactly the point that
> > I'm trying to make. As a 'landlord', I might very well want to have
> > some kind of 'landlord' role that isn't directly a superuser but which
> > could *become* a superuser by having been GRANT'd a superuser role- but
> > I certainly don't want that role's objects to be able to be messed with
> > by the tenant.
>
> > If one of those other non-superuser roles is, itself, a role that can
> > become a superuser
>
> If you have a sandbox-superuser who can do anything within the sandbox but nothing outside the sandbox, then you need a pretty good wall at the periphery of the sandbox. Breaking sandbox-superuser-ishness into multiple distinct privileges rather than one monolithic privilege doesn't change the need for a good wall at the periphery. The pg_manage_database_objects role doesn't encompass all sandbox-superuser privileges, but it is on that side of the wall.
>
> We could agree to move the wall a little, and say that non-superuser roles who have the ability to become superusers are on the other side of the wall. That's fine. I'd have to rework the patch a bit, but conceptually that seems doable. We could also say that non-superusers who are members of privileged roles (pg_execute_server_programs, pg_signal_backend, etc) are likewise on the other side of that wall.
>
> Does that work?

I'd much rather we go down the path that Robert had suggested where we
find a way to make a connection between the tenant role and everything
that they create, and leave everything that is outside of that box on
the other side of the 'wall'. There's also the risk that the landlord
creates a role one day but then GRANT's superuser rights to that role on
another day, that happened to be after the tenant managed to gain
control of that role. That kind of thing is something we should work
hard to make difficult to happen- the landlord should have to explicitly
give the tenant control over something that the landlord creates, it
shouldn't happen automagically.

Having hard-coded lists of which predefined roles are 'ok' and which
aren't sounds generally bad and I don't think we'd actually want to
include all predefined roles in that list either (even if it'd be fine
today, which I don't think it is given things like pg_monitor and
pg_signal_backend, though perhaps there could be some debate over
those...).

Thanks,

Stephen