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
