Re: Granting SET and ALTER SYSTE privileges for GUCs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <joe(at)crunchydata(dot)com>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: 2022-03-30 13:26:21
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

After sleeping on it, I have a modest proposal for simplifying
these issues. Consider this design:

1. In the SET code path, we assume (without any catalog lookup)
that USERSET GUCs can be set. Only for SUSET GUCs do we perform
a permissions lookup. (ALTER SYSTEM does a lookup in both cases.)

2. Given this, the default ACL for any GUC can be empty, greatly
simplifying all these management issues. Superusers could do what
they want anyway, so modeling an "owner's default grant" becomes

What this loses is the ability to revoke public SET permissions
on USERSET GUCs. I claim that that is not so valuable as to
justify all the complication needed to deal with it. (If a GUC
seems to require some defenses, why is it USERSET?) Avoiding
a permissions lookup in the default SET code path seems like
a pretty important benefit, too. If we force that to happen
it's going to be a noticeable drag on functions with SET clauses.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2022-03-30 13:44:02 Re: In-placre persistance change of a relation
Previous Message Magnus Hagander 2022-03-30 13:04:30 Re: Add parameter jit_warn_above_fraction