Re: Granting SET and ALTER SYSTE privileges for GUCs

On Tue, Mar 29, 2022 at 9:00 PM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
wrote:

> A grant or revoke on an unrecognized custom parameter will create a SUSET
> placeholder,

[...]

> which cleans up the problem, with one exception: if the user executes a
> "revoke set on parameter some.such from public" prior to loading the module
> which defines parameter some.such, that revoke won't be retained. That
> doesn't seem entirely wrong to me, since no privilege to set the parameter
> existed when the revoke was performed, but rather was granted along with
> the creation of the parameter, but it also doesn't seem entirely right.
> Maybe revoke commands (but not grant commands) should error on unrecognized
> custom parameters?

The only revoke role target that makes sense here is the default grant
given to public. Aside from that technicality the grant system is purely
additive and so only the GRANTS end up retained so far as perpetual state
is concerned.

For a revoke that doesn't target public we should remove the corresponding
unrecognized setting grant if one is present. We don't generally/always
raise a notice if a revoke doesn't actually cause something to be ungranted
- though I'm partial to being so informed. I suppose we could distinguish
the cases where the not-yet-loaded setting name is unrecognized by the
system from the one where it is recognized but the grant is actually on a
different role (or a revoke entry from public for the setting name is
present).

For a revoke of an unknown setting from public we should keep an entry
somewhere that tells the system that the default grant to public for that
setting has been revoked. Maybe there isn't the same timing concern here
as there is for GRANT, but if only for symmetry it seems like a good thing
to implement.

I have the impression I'm missing something in what I wrote above but
cannot quite figure out what. In any case as a first pass at this the
behavior described is kinda what I'm expecting.

David J.

P.S.

Skimming the patch we are, to my agreement, not touching the ALTER DEFAULT
PRIVILEGES command to work with this feature. Should the omission be noted
explicitly? At least in the commit message I would think. Though the
sentence in [1] "Also, these default privilege settings can be overridden
using the ALTER DEFAULT PRIVILEGES command." is rendered only partially
correct.

[1] https://www.postgresql.org/docs/current/ddl-priv.html

P.P.S.

+ The default privileges for a <literal>user</literal> parameter allow
+ <literal>PUBLIC</literal> to <command>SET</command> and
+ <command>RESET</command> the assigned value. By default,
+ <literal>PUBLIC</literal> has no privileges on
+ <literal>postmaster</literal>, <literal>superuser-backend</literal>,
+ <literal>internal</literal>, <literal>backend</literal>,
+ <literal>sighup</literal>, and <literal>superuser</literal> parameters.

Can we rephrase this to something like:

By default, PUBLIC has no privileges on parameters in the postmaster, ...,
and superuser contexts.

pg_settings.context exists and those are the values found there. My
initial interpretation of the wording was the postmaster, etc..., were
themselves parameters, not containers for many parameters.