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

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, Noah Misch <noah(at)leadboat(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jacob Champion <pchampion(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "chap(at)anastigmatix(dot)net" <chap(at)anastigmatix(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Date: 2021-10-20 17:32:51
Message-ID: 2BBD81F2-F64E-4345-B48F-040F338DFF5D@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Oct 20, 2021, at 10:20 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> I'm trying to suggest an approach that is flexible enough (not limited
> to superusers), but also addresses Noah's complaint that ordinary role
> membership should not implicitly control event trigger firing.
>
> The most direct way to address Noah's complaint is to make a new
> explicit user option BYPASS_EVENT_TRIGGERS, which controls whether
> event triggers fire or not.

I'd like to have a much clearer understanding of Noah's complaint first. There are multiple things to consider: (1) the role which owns the trigger, (2) the role which is performing an action which would cause the trigger to fire, (3) the set of roles role #1 belongs to, (4) the set of roles role #1 has ADMIN privilege on, (5) the set of roles that role #2 belongs to, and (6) the set of roles that role #2 has ADMIN privilege on. Maybe more?

And that's before we even get into having roles own other roles, which the event trigger patches *do not depend on*. In the patch set associated with this thread, the event trigger stuff is in patches 0014 and 0015. The changes to CREATEROLE and role ownership are not until patches 0019, 0020, and 0021. (I'm presently writing another set of emails to split this all into four threads/patch sets.)

I'd like to know precisely which combinations of these six things are objectionable, and why. There may be a way around the objections without needing to create new user options or new privileged roles.

> Another benefit of this is that it makes this event trigger change
> independent of the Role Self-Administration discussion, so it could
> potentially be committed sooner.

I don't think the two are related, though I can understand the confusion. That is, in fact, a small part of why I'm splitting the patches into different email threads.


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2021-10-20 17:51:41 [RFC] speed up count(*)
Previous Message Jeff Davis 2021-10-20 17:20:28 Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)