Re: Granting control of SUSET gucs to non-superusers

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Granting control of SUSET gucs to non-superusers
Date: 2021-05-01 00:02:09
Message-ID: 608C9A81.3020006@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/30/21 19:19, Mark Dilger wrote:

> We could certainly debate which GUCs could be used to escape the sandbox
> vs. which ones could not, but I would prefer a design that allows the
> provider to make that determination.

I find myself wondering how many GUCs flagged SUSET are not flagged that way
because of a determination already made that they could be used to escape.
(Maybe some of the logging ones, only usable to conceal your escape.)

But there might be ways for a provider, scrutinizing each of those
individually, to conclude "this will not allow escape from the sandbox
/I/ have set up, provided the value being set satisfies constraints
x and y" ... a generalization of the LOAD from $libdir/plugins idea.

So that suggests to me some mechanism where a provider could grant
setting foo to role bar using validator baz().

Can SUSET GUCs be set from SECURITY DEFINER functions? Maybe there are
already the pieces to do that, minus some syntax sugar.

Regards,
-Chap

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-05-01 00:13:33 Re: Granting control of SUSET gucs to non-superusers
Previous Message Bingyu Shen 2021-04-30 23:55:18 Log enhancement for aclcheck permissions failures