Re: privileges for ALTER ROLE/DATABASE SET
От | Nathan Bossart |
---|---|
Тема | Re: privileges for ALTER ROLE/DATABASE SET |
Дата | |
Msg-id | 20220722222516.GA3998906@nathanxps13 обсуждение исходный текст |
Ответ на | Re: privileges for ALTER ROLE/DATABASE SET (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: privileges for ALTER ROLE/DATABASE SET
|
Список | 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
В списке pgsql-hackers по дате отправления: