Re: Granting control of SUSET gucs to non-superusers - Mailing list pgsql-hackers

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, May 3, 2021 at 12:25 PM Mark Dilger
> <mark.dilger@enterprisedb.com> wrote:
> > As things stand, all custom variables defined via the DefineCustom{Bool,Int,Real,String,Enum}Variable are placed in
theCUSTOM_OPTIONS config_group.  We could add a role for controlling any SUSET CUSTOM_OPTIONS GUCs, or we could extend
thosefunctions to take a config_group option, or perhaps some of both.  I haven't thought too much yet about whether
allowingextensions to place a custom GUC into one of the predefined groups would be problematic.  Any thoughts on that? 
>
> Well...
>
> One idea would be to get rid of PGC_SUSET altogether and instead have
> a set of flags associated with each GUC, like PGF_SERVER_LOG,
> PGF_CORRUPT_DATA, PGF_CRASH_SERVER. Then you could associate those
> flags with particular predefined roles and grant them out to whoever
> you want.
>
> So if a GUC is flagged PGF_SERVER_LOG|PGF_CRASH_SERVER, then the
> assumption is that it's security-sensitive because it both lets you
> alter the contents of the server log and also lets you crash the
> server. If you are granted both pg_server_log and pg_crash_server, you
> can set it, otherwise not.
>
> This is just wild brainstorming, but my point is that I don't think
> doing it by options groups is particularly good, because it doesn't
> really have any relationship to why those things are marked SUSET in
> the first place. To take an example involving functions rather than
> GUCs, the pageinspect functions are super-user only because you can
> crash the server by inspecting malformed data that you supply as an
> arbitrarily literal, but AFAIK the functions in pgstattuple have no
> similar hazard, and are just super-only because we don't really know
> who the superuser wants to authorize, and maybe it's not everybody. So
> those cases are really different, even though both are extensions. I
> think the same likely holds true for GUCs.

In general, I agree that we should be looking at predefined roles as
being similar to the Linux capabilities system- defining certain kinds
of operations which the user who has that role is allowed to do, and
then both in-core and extensions can make decisions based on what
capabilities the user has been GRANT'd.

Hopefully that would limit the amount of cases where a given capability
ends up being overly broad while at the same time allowing extensions to
sensibly be able to use the defined capabilities for their own needs.

As we do in other places, we should make it clear when a certain
capability allows a user with that capability to gain superuser access
as that may not always be clear to a user.

One thing that seems missing from this discussion and is part of what
paused my effort on the 'admin' role proposed towards the end of the
last cycle is that we really need to consider how this all plays with
ALTER SYSTEM and not just SUSET GUCs but also other (eg: POSTMASTER,
SIGHUP) GUCs.  That is- imv we should have a sensible solution for
more-or-less all GUCs and which would allow a non-superuser to be able
to set POSTMASTER and SIGHUP GUCs (and perhaps others..) through
ALTER SYSTEM.

Thanks,

Stephen