Re: CREATEROLE and role ownership hierarchies

Greetings,

On Mon, Jan 24, 2022 at 16:42 Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Jan 24, 2022 at 4:23 PM Stephen Frost <sfrost(at)snowman(dot)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.

Being able to create and drop users is, in fact, effectively a
superuser-only task today. We could throw out the entire idea of role
ownership, in fact, as being entirely unnecessary when talking about that
specific task.

> 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.

This is an argument to drop the role ownership concept, as I view it.
Privileges are driven by membership today and inventing some new
independent way to do that is increasing confusion, not improving things.
I disagree that adding role ownership should necessarily change how the
regular GRANT privilege system works or throw away basic concepts of that
system which have been in place for decades. Increasing the number of
independent ways to answer the question of “what users have what rights on
object X” is an active bad thing. Anything that cares about object access
will now also have to address role ownership to answer that question, while
if we don’t include this one change then they don’t need to directly have
any concern for ownership because regular object privileges still work the
same way they did before.

> 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.

Superuser is a problem specifically because it gives people access to do
absolutely anything, both for security and safety concerns. Disallowing a
way to curtail that same risk when it comes to role ownership invites
exactly those same problems.

I appreciate that there’s an edge between the ownership system being
proposed and the existing role membership system, but we’d be much better
off trying to minimize the amount that they end up overlapping- role
ownership should be about managing roles.

To push back on the original “tenant” argument, consider that one of the
bigger issues in cloud computing today is exactly the problem that the
cloud managers can potentially gain access to the sensitive data of their
tenants and that’s not generally viewed as a positive thing. This change
would make it so that every landlord can go and SELECT from the tables of
their tenants without so much as a by-your-leave. The tenants likely don’t
like that idea, and almost as likely the landlords in many cases aren’t
thrilled with it either. Should the landlords be able to DROP the tenant
due to the tenant not paying their bill? Of course, and that should then
eliminate the tenant’s tables and other objects which take up resources,
but that’s not the same thing as saying that a landlord should be able to
unlock a tenant’s old phone that they left behind (and yeah, maybe the
analogy falls apart a bit there, but the point I’m trying to get at is that
it’s not as simple as it’s being made out to be here and we should think
about these things and not just implicitly grant all access to the owner
because that’s an easy thing to do- and is exactly what viewing owners as
“mini superusers” does and leads to many of the same issues we already have
with superusers).

Thanks,

Stephen

>