Re: Fixing insecure security definer functions
От | Andrew Dunstan |
---|---|
Тема | Re: Fixing insecure security definer functions |
Дата | |
Msg-id | 60531.24.211.165.134.1171419417.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Fixing insecure security definer functions (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Peter Eisentraut wrote: > Regarding the advisory on possibly insecure security definer functions > that I just sent out (by overriding the search path you can make the > function do whatever you want with the privileges of the function > owner), the favored solution after some initial discussion in the core > team was to save the search path at creation time with each function. > This measure will arguably also increase the robustness of functions in > general, and it seems to be desirable as part of the effort to make > plan invalidation work. > > Quite probably, there will be all sorts of consequences in terms of > backward compatibility and preserving the possibility of valid uses of > the old behavior and so on. So I'm inviting input on how to fix the > problem in general and how to avoid the mentioned follow-up problems in > particular. Maybe we need an option on CREATE ... SECURITY DEFINER to allow the function to inherit the caller's search path. cheers andrew
В списке pgsql-hackers по дате отправления: