Re: Granting control of SUSET gucs to non-superusers

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Granting control of SUSET gucs to non-superusers
Date: 2021-05-03 17:43:32
Message-ID: 60903644.1010105@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/03/21 13:23, Robert Haas wrote:
> On Mon, May 3, 2021 at 11:45 AM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>> I guess I was thinking, but forgot to convey to the keyboard, that the
>> existence of a non-empty extra_check_hooks chain on a SUSET GUC (which
>> could only have been attached from a shared preload library) would
>> implicitly change SUSET to mean settable whenever accepted by the hook(s).
>
> Sure, but the hook still needs a way to know which users are entitled
> to set the GUC.

I was contemplating a version 0 with only that minimal support in core
for allowing a shared preload library to set such hooks (and allowing
include-with-a-role in config files), assuming service providers already
do sophisticated building of stuff to construct the environments they
provide, and a C shared object with hooks that enforce their designed
constraints wouldn't be an onerous burden on top of that.

Such providers could then be the laboratories of democracy building
various forms of such things, and if one of those ends up having a
reasonably general configuration mechanism and gets offered as a
contrib module later or for inclusion in core, well, that's version 0.5.

Regards,
-Chap

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2021-05-03 17:51:29 Re: function for testing that causes the backend to terminate
Previous Message Peter Geoghegan 2021-05-03 17:38:37 Re: MaxOffsetNumber for Table AMs