On Mon, Jan 24, 2022 at 4:23 PM Stephen Frost <sfr...@snowman.net> wrote: > The idea behind this patch is to enable creation and dropping of roles, which > isn’t possible now without being effectively a superuser. > > Forcing owners to also implicitly have all rights of the roles they create is > orthogonal to that and an unnecessary change.
I just took a look at the first email on this thread and it says this: >>> These patches have been split off the now deprecated monolithic "Delegating >>> superuser tasks to new security roles" thread at [1]. Therefore I think it is pretty clear that the goals of this patch set include being able to delegate superuser tasks to new security roles. And having those tasks be delegated but *work randomly differently* is much less useful. > I am not saying that we would explicitly set all cases to be noninherit or > that we would even change the default away from what it is today, only that > we should use the existing role system and it’s concept of > inherit-vs-noninherit rather than throwing all of that away. INHERIT vs. NOINHERIT is documented to control the behavior of role *membership*. This patch is introducing a new concept of role *ownership*. It's not self-evident that what applies to one case should apply to the other. > Further, being able to require a SET ROLE before running a given operation is > certainly a benefit in much the same way that having a user have to sudo > before running an operation is. That's a reasonable point of view, but having things work similarly to what happens for a superuser is ALSO a very big benefit. In my opinion, in fact, it is a far larger benefit. -- Robert Haas EDB: http://www.enterprisedb.com
