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
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 |