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

Greetings,

On Tue, Oct 19, 2021 at 18:26 Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
wrote:

>
>
> > On Oct 19, 2021, at 3:18 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> >
> > On Tue, 2021-10-19 at 13:17 -0700, Mark Dilger wrote:
> >> Wouldn't it be much cleaner to have superuser bypass the trigger?
> >
> > Maybe it could be a user property like "BYPASS_EVENT_TRIGGERS", and
> > only superusers could adjust it (like the SUPERUSER and REPLICATION
> > properties).
> >
> > I suppose it would default to BYPASS_EVENT_TRIGGERS for superusers and
> > not for non-superusers. A little awkward to have different defaults,
> > but it seems sensible in this case.
> >
> > Would this bypass all event triggers, or only the event triggers of
> > another user?
>
> The difficulty is that non-superuser owned event triggers could be
> something of a minefield for scripts run as superuser. The cleanest way
> around that would be to have them never fire in response to superuser
> actions. Installations could still have event triggers that cover all
> users, including superusers, as long as they have those triggers owned by
> superuser.
>
> The implementation in the patch set does this, but with finer grained
> precision, because the universe of roles is divided into more than just
> superuser vs. non-superuser.

This last point is particularly important. Non-super users may be able to
become superuser and those roles which are able to need to also be
protected. Only protecting superuser roles themselves is *not* enough.

Thanks,

Stephen

>