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 |
Message-ID: | 212076.1648646781@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
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
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 |