On Mon, Jan 24, 2022 at 4:23 PM Stephen Frost <sfrost@snowman.net> wrote:
> The idea behind this patch is to enable creation and dropping of roles, which isn’t possible now without being
effectivelya 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"
threadat [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
fromwhat it is today, only that we should use the existing role system and it’s concept of inherit-vs-noninherit rather
thanthrowing 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
waythat 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