Re: Granting SET and ALTER SYSTE privileges for GUCs
От | Andrew Dunstan |
---|---|
Тема | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Дата | |
Msg-id | fb91d2c9-9719-7916-83f8-1a1e0ae93670@dunslane.net обсуждение исходный текст |
Ответ на | Re: Granting SET and ALTER SYSTE privileges for GUCs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Granting SET and ALTER SYSTE privileges for GUCs
|
Список | 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
В списке pgsql-hackers по дате отправления: