> On Apr 30, 2021, at 4:28 PM, Stephen Frost <sfrost@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
wecan competently fit new GUCs into these groups (or invent new ones if a new GUC truly falls outside all existing but
Iwould 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,
becauseproviders can just spin up a virtual machine per tenant and give each tenant superuser privileges on their
respectiveVM. 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
tenantwill depend very much on the division of responsibility. If the provider is managing replication, then control
oversession_replication_role and wal_compression is unlikely to be handed to the tenant, but if the tenant is
responsiblefor 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
sandboxthe provider has designed?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
