Hi hackers,
Presently, if a role has privileges to SET a parameter, it is able to ALTER
ROLE/DATABASE SET that parameter, provided it otherwise has permission to
alter that role/database. This includes cases where the role only has SET
privileges via the new pg_parameter_acl catalog. For example, if a role is
granted the ability to SET a PGC_SUSET GUC, it also has the ability to
ALTER ROLE/DATABASE SET that GUC. A couple of recent threads have alluded
to the possibility of introducing a new set of privileges for ALTER
ROLE/DATABASE SET [0] [1], so I thought I'd start the discussion.
First, is it necessary to introduce new privileges, or should the ability
to SET a parameter be enough to ALTER ROLE/DATABASE SET it? AFAICT this is
roughly the behavior before v15, but it simply disallowed non-superusers
from setting certain parameters.
Second, if new privileges are required, what would they look like? My
first instinct is to add GRANT ALTER ROLE ON PARAMETER and GRANT ALTER
DATABASE ON PARAMETER.
Thoughts?
[0] https://postgr.es/m/1732511.1658332210%40sss.pgh.pa.us
[1] https://postgr.es/m/20220714225735.GB3173833%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
