Re: CREATEROLE and role ownership hierarchies
От | Mark Dilger |
---|---|
Тема | Re: CREATEROLE and role ownership hierarchies |
Дата | |
Msg-id | 61DB6A06-8625-49A2-8EB6-6295AA5AE1EC@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: CREATEROLE and role ownership hierarchies (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: CREATEROLE and role ownership hierarchies
(Stephen Frost <sfrost@snowman.net>)
|
Список | pgsql-hackers |
> On Jan 24, 2022, at 2:21 PM, Stephen Frost <sfrost@snowman.net> wrote: > > To push back on the original “tenant” argument, consider that one of the bigger issues in cloud computing today is exactlythe problem that the cloud managers can potentially gain access to the sensitive data of their tenants and that’snot generally viewed as a positive thing. +1. This is a real problem. I have been viewing this problem as separate from the one which role ownership is intendedto fix. Do you have a suggestion about how to tackle the problems together with less work than tackling them separately? > This change would make it so that every landlord can go and SELECT from the tables of their tenants without so much asa by-your-leave. I would expect that is already true. A user with CREATEROLE can do almost everything. This patch closes some CREATEROLErelated security problems, but not this one you mention. > The tenants likely don’t like that idea +1 > , and almost as likely the landlords in many cases aren’t thrilled with it either. +1 > Should the landlords be able to DROP the tenant due to the tenant not paying their bill? Of course, and that should theneliminate the tenant’s tables and other objects which take up resources, but that’s not the same thing as saying thata landlord should be able to unlock a tenant’s old phone that they left behind (and yeah, maybe the analogy falls aparta 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 weshould 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 withsuperusers). This is a pretty interesting argument. I don't believe it will work to do as you say unconditionally, as there is stilla need to have CREATEROLE users who have privileges on their created roles' objects, even if for no other purpose thanto be able to REASSIGN OWNED BY those objects before dropping roles. But maybe there is also a need to have CREATEROLEusers who lack that privilege? Would that be a privilege bit akin to (but not the same as!) the INHERIT privilege? Should I redesign for something like that? I like that the current patch restricts CREATEROLE users from granting privileges they themselves lack. Would such a newprivilege bit work the same way? Imagine that you, "stephen", have CREATEROLE but not this new bit, and you create me,"mark" as a tenant with CREATEROLE. Can you give me the bit? Or does the fact that you lack the bit mean you can't giveit to me, either? Other suggestions? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления:
Следующее
От: Mahendra Singh ThalorДата:
Сообщение: Re: Collecting statistics about contents of JSONB columns