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

On Thu, 2021-10-28 at 11:02 -0700, Mark Dilger wrote:
> It feels to me that the traditional concept of users and groups could
> map, one-to-one, onto users and roles, but we've mapped both users
> and groups, many-to-one, onto roles, leaving no distinct concept of
> groups, and now we're proposing adding a concept called "tenant" that
> means something like "group".  I find that simultaneously helpful and
> pretty confusing.

That's a good point. There are a lot of concepts involved; adding one
more could certainly cause confusion.

But I don't think the concept of role ownership has zero potential
confusion, either. For instance, I could certainly imagine a user A
creating a role B (and therefore owning it), and then doing "GRANT A TO
B". Is there a reason to do that, or is the user confused about what
membership versus ownership mean?

> Noah's concern, as I understood it, was not about roles owning roles,
> but about role membership being what controls if an event trigger
> fires.  If anything, that concern stems from the lack of role
> ownership, not the existence of it, because I wrote the event trigger
> patch set to not depend on the role ownership patch set.

Your patch[0] causes role membership to control whether and event
trigger fires. If it was solely based on role *ownership* and had
nothing to do with role *membership*, that does seem better to me.

[0] 
https://postgr.es/m/914FF898-5AC4-4E02-8A05-3876087007FB@enterprisedb.com

Regards,
    Jeff Davis