Re: privileges for ALTER ROLE/DATABASE SET

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

On Fri, Jul 22, 2022 at 04:16:14PM -0400, Tom Lane wrote:
> 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?

Actually, I think my vote is to do nothing, except for perhaps updating the
documentation to indicate that SET privileges on a parameter are sufficient
for ALTER ROLE/DATABASE SET (given you have the other required privileges
for altering the role/database). I can't think of a use-case for allowing
a role to SET a GUC but not change the session default for another role.
And I agree that requiring extra permissions for this feels excessive.
Maybe someone else has a use-case in mind, though. I figured it would be
good to hash this out prior to 15.0, at which point changing the behavior
would become substantially more difficult.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-07-22 22:33:59 Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS
Previous Message Tom Lane 2022-07-22 21:55:28 Re: PANIC: wrong buffer passed to visibilitymap_clear