Horton

Re: Granting SET and ALTER SYSTE privileges for GUCs

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Joshua Brindle <joshua.brindle@crunchydata.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Joe Conway <joe@crunchydata.com>
Date: 2022-03-30T15:12:46Z
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


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Commits

  1. Allow granting SET and ALTER SYSTEM privileges on GUC parameters.