> 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
