Re: CREATEROLE and role ownership hierarchies
| От | Stephen Frost |
|---|---|
| Тема | Re: CREATEROLE and role ownership hierarchies |
| Дата | |
| Msg-id | CAOuzzgq_j9ycUfQ89G1tr9n+Rs74G==OoNbZWJbAq=mNiArT6w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CREATEROLE and role ownership hierarchies (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: CREATEROLE and role ownership hierarchies
(Mark Dilger <mark.dilger@enterprisedb.com>)
Re: CREATEROLE and role ownership hierarchies (Mark Dilger <mark.dilger@enterprisedb.com>) Re: CREATEROLE and role ownership hierarchies (Mark Dilger <mark.dilger@enterprisedb.com>) Re: CREATEROLE and role ownership hierarchies (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
Greetings,
On Mon, Jan 24, 2022 at 16:42 Robert Haas <robertmhaas@gmail.com> wrote:
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 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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tomas VondraДата:
Сообщение: Re: Collecting statistics about contents of JSONB columns
Следующее
От: Tom LaneДата:
Сообщение: Re: Replace uses of deprecated Python module distutils.sysconfig