> On Apr 30, 2021, at 4:28 PM, Stephen Frost <sfr...@snowman.net> wrote:
>
> “Can’t be used to gain superuser” may be a sufficiently clear grouping, as
> was more or less contemplated by the “admin” approach. If that doesn’t work
> though then we need an understanding of what the limits on these groups are,
> so we can competently fit new GUCs into these groups (or invent new ones if a
> new GUC truly falls outside all existing but I would expect that to be a
> rather rare case..).
When I first heard that providers want to build sandboxes around PostgreSQL, I
thought the idea was a little silly, because providers can just spin up a
virtual machine per tenant and give each tenant superuser privileges on their
respective VM. Who cares if they mess it up after that?
The problem with that idea turns out to be that the providers want to take
responsibility for some of the database maintenance, possibly including
backups, replication, etc. I think the set of controls the provider hands over
to the tenant will depend very much on the division of responsibility. If the
provider is managing replication, then control over session_replication_role
and wal_compression is unlikely to be handed to the tenant, but if the tenant
is responsible for their own replication scheme, it might be.
Viewing all of this in terms of which controls allow the tenant to escape a
hypothetical sandbox seems like the wrong approach. Shouldn't we let service
providers decide which controls would allow the tenant to escape the specific
sandbox the provider has designed?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
