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.
--
Robert Haas
EDB: http://www.enterprisedb.com
