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

Greetings,

* Mark Dilger (mark.dilger@enterprisedb.com) wrote:
> > On Nov 1, 2021, at 1:13 PM, Stephen Frost <sfrost@snowman.net> wrote:
> >> Having Batman *own* all residents in Gotham city would work, if we can agree on a role ownership system.  It has
thedownside that only a role's (direct or indirect) owner can do the auditing, though.  That's more flexible than what
wehave today, where only superuser can do it, but maybe some people would want to argue for a different solution with
evenmore flexibility?  A grantable privilege perhaps?  But whatever it is, the reasoning about who gets audited and who
doesnot must be clear enough that Batman can pass a compliance audit. 
> >
> > What about roles which Batman owns but which he *doesn't* want the event
> > trigger to fire for?
>
> I think Batman just has the event trigger exit early for that.  There is nothing we can hardcode for filtering users
intoand out of the trigger that will be as flexible as the logic that Batman can implement in the trigger itself.  We
onlyneed to worry about Batman over stepping his authority.  It's not our job to filter further than that. 

As noted in my other email you're likely currently reading, this
presumes that Batman is the author of the trigger and is able to make
such changes.  I'm also not thrilled with the presumption that, even if
batman is the author and maintainer, that batman would then have to
write in such exclusions for what strikes me as a pretty commonly wished
for use-case.

> > Note that event triggers are not strictly limited to the auditing case.
> > Viewing them through that lense masks other quite common use-cases which
> > are also importnat to consider (like preventing many users, but not all,
> > from being able to DROP objects as a clear example).
>
> Nothing in my proposal limits what superusers can do with event triggers they create.  The issue under discussion is
entirelyto do with what non-superusers are allowed to do with event triggers.  I see no reason why some ordinary role
"joe"should be allowed to thwart DROP commands issued on a table that "joe" doesn't own by roles that "joe" doesn't
own. Maybe "own" here should be "have ADMIN on", but it has to be something. 

I agree that we're talking about non-superuser event triggers.  I wasn't
suggesting that a non-superuser role 'joe' be able to create event
triggers that impact roles that 'joe' doesn't have rights of some kind
over.  I'm not quite following how your response here is addressing the
point that I brought up in what was quoted above it.

Thanks,

Stephen