Re: Granting control of SUSET gucs to non-superusers

On Sat, May 1, 2021 at 12:37 PM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
> Maybe version 0 is where the provider just builds a shared object
> to go in shared_preload_libraries. The provider has probably already
> done a bunch of other stuff more challenging than that.
>
> The GUC system would have to expose a way for the shared object to
> chain extra_check_hooks off existing GUCs. An extra_check_hook can check
> both the value and the role of the caller.

I think there are two parts to this problem. First, the SP needs to be
able to delegate to some users but not others the ability to set
superuser GUCs. Second, the SP needs to be able to control which GUCs
the privileged users get to set and perhaps to what values. A hook of
the type you propose here seems like it might work reasonably well for
that second part, but it's not totally obvious to me how it helps with
the first part.

Instead of going to the extreme of one predefined role per GUC, maybe
we could see if the PGC_SUSET GUCs could be divided into buckets based
on the reason they are so marked? For example, log_parser_stats,
log_planner_stats, log_executor_stats, log_statement_stats,
log_btree_build_stats, trace_locks, trace_userlocks, trace_lwlocks,
log_min_duration_statement, and a bunch of others are probably all
SUSET just on the theory that only the superuser should have the right
to control what ends up in the log. But we could make a predefined
role that represents the right to control what ends up in the log, and
then all of those GUCs could be tied to that role. Is that too
coarse-grained? It might be.

One problem with having a separate predefined role for every PGC_SUSET
GUC is that it's no help for extensions. Both auto_explain and
pg_stat_statements have such GUCs, and there may be out-of-core
extensions that do as well. We should try to come up with a system
that doesn't leave them out in the cold.

--
Robert Haas
EDB: http://www.enterprisedb.com