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

On Mon, Oct 25, 2021 at 12:20 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Exactly. That's the main point. Also, it's currently a best practice for
> > only non-LOGIN roles to have members. The proposed approach invites folks to
> > abandon that best practice. I take the two smells as a sign that we'll regret
> > adopting the proposal, despite not knowing how it will go seriously wrong.
>
> This seems like a pretty good point, which leads me to again think that
> we should explicitly add a way for an individual who can create event
> triggers to be able to specify for whom the event trigger should fire,
> and only allow them to specify roles other than their own provided they
> have been given that authority (either explicitly somehow or implicitly
> based on some defined access that they have to that other role).

I agree that Noah has a reasonably good point here. I don't think it's
a total slam-dunk but it it's certainly not a stupid argument.
Conceding that point for the purposes of discussion, I don't
understand how this kind of proposal gets us out from under the
problem. Surely, it can't be the case that user X can cause event
trigger E to run as user Y unless X can become Y, because to do so
would allow X to usurp Y's privileges, except in the corner case where
Y never does anything that can trigger an event trigger. But if X has
to be able to become Y in order to force E to be run by Y, then I
think we've made no progress in addressing Noah's complaint.

--
Robert Haas
EDB: http://www.enterprisedb.com