Re: pgsql: Fix search_path to a safe value during maintenance operations.
От | Jeff Davis |
---|---|
Тема | Re: pgsql: Fix search_path to a safe value during maintenance operations. |
Дата | |
Msg-id | fd425bbacb86a00b85aabcbaa78d55c55cbf6fc3.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: pgsql: Fix search_path to a safe value during maintenance operations. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pgsql: Fix search_path to a safe value during maintenance operations.
|
Список | pgsql-hackers |
On Mon, 2023-07-31 at 16:06 -0400, Robert Haas wrote: > if you > include in your search_path a schema to which some other user can > write, you are pretty much agreeing to execute code provided by that > user. Agreed on all counts here. I don't think it's reasonable for us to try to make such a setup secure, and I don't think users have much need for such a setup anyway. > One thing we might be able to do to prevent that sort of thing is to > have a feature to prevent "accidental" code execution, as in the > "function trust" mechanism proposed previously. Say I trust all users > who can SET ROLE to me and/or who inherit my privileges. Additionally > I can decide to trust users who do neither of those things by some > sort of explicit declaration. If I don't trust a user then if I do > anything that would cause code supplied by that user to get executed, > it just errors out: > > ERROR: role "rhaas" should not execute arbitrary code provided by > role "jconway" > HINT: If this should be allowed, use the TRUST command to permit it. +1, though I'm not sure we need an extensive trust mechanism beyond what we already have with the SET ROLE privilege. > And > we probably also still need to find ways to control search_path in a > lot more widely than we do today. Otherwise, even if stuff is > technically secure, it may just not work. +1. Regards, Jeff Davis
В списке pgsql-hackers по дате отправления: