Re: Granting control of SUSET gucs to non-superusers

> On May 1, 2021, at 7:07 AM, Chapman Flack <chap@anastigmatix.net> wrote:
>
> On 04/30/21 22:00, Mark Dilger wrote:
>> 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?
>
> I agree that sounds more like the right approach. It seems to me that
> in the general case, a provider might conclude that setting foo is
> safe in the provider-designed sandbox /if the value being assigned
> to it satisfies some provider-determined conditions/.

> So it seems the machinery is already in place with which a provider
> could allow a chosen set of SUSET-only GUCs to be set, to values that
> satisfy provider-determined conditions, by users in a provider-chosen
> role.

> Some pretty syntax like GRANT SETTING foo TO ROLE bar WHERE cond;
> would simply be sugar on top.

I agree with everything you say here.  I have some thoughts about usability....

I'd like the experience for the tenant to be as similar as possible to having superuser privileges on their own
cluster. The tenant may be migrating an application from a database that they currently manage themselves, and any need
touse different syntax from what they have been using is an extra hurdle that could derail the migration. 

Extra syntax for use by the service provider seems much easier to justify.

If the service provider can install extra role-aware check_hooks for gucs, and if the include directive for
postgresql.confcan specify a role under which a postgresql.conf.tenant file is processed, then the tenant can port
theirapplication and their config file and the only things that should break are those things the provider has
intentionallyprohibited. 

Does this sound like a reasonable approach?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company