Re: Granting SET and ALTER SYSTE privileges for GUCs

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, 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 15:12:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 3/30/22 09:26, Tom Lane wrote:
> 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
> unnecessary.
> 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.

The last point is telling, so +1



Andrew Dunstan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-03-30 15:27:36 Re: Extend compatibility of PostgreSQL::Test::Cluster
Previous Message Mark Dilger 2022-03-30 14:45:36 Re: Granting SET and ALTER SYSTE privileges for GUCs