> On Jan 24, 2022, at 2:21 PM, Stephen Frost <sfr...@snowman.net> wrote:
>
> 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.
+1. This is a real problem. I have been viewing this problem as separate from
the one which role ownership is intended to 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 as a by-your-leave.
I would expect that is already true. A user with CREATEROLE can do almost
everything. This patch closes some CREATEROLE related 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 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).
This is a pretty interesting argument. I don't believe it will work to do as
you say unconditionally, as there is still a need to have CREATEROLE users who
have privileges on their created roles' objects, even if for no other purpose
than to be able to REASSIGN OWNED BY those objects before dropping roles. But
maybe there is also a need to have CREATEROLE users 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 new privilege 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 give it to me, either?
Other suggestions?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
