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
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 |