Re: Granting SET and ALTER SYSTE privileges for GUCs
От | Tom Lane |
---|---|
Тема | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Дата | |
Msg-id | 212076.1648646781@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Granting SET and ALTER SYSTE privileges for GUCs (Joshua Brindle <joshua.brindle@crunchydata.com>) |
Ответы |
Re: Granting SET and ALTER SYSTE privileges for GUCs
Re: Granting SET and ALTER SYSTE privileges for GUCs |
Список | 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 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. regards, tom lane
В списке pgsql-hackers по дате отправления: