Re: privileges for ALTER ROLE/DATABASE SET

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: privileges for ALTER ROLE/DATABASE SET
Date: 2022-07-22 20:16:14
Message-ID: 744950.1658520974@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> 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?

Clearly, you need enough privilege to SET the parameter, and you need
some sort of management privilege on the target role or DB. There
might be room to discuss what that per-role/DB privilege needs to be.
But I'm very skeptical that we need to manage this at the level
of the cross product of GUCs and roles/DBs, which is what you seem
to be proposing. That seems awfully unwieldy, and is there really
any use-case for it?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-07-22 20:19:45 Re: make -C libpq check fails obscurely if tap tests are disabled
Previous Message Nathan Bossart 2022-07-22 20:04:22 privileges for ALTER ROLE/DATABASE SET