Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions |
Дата | |
Msg-id | CAGECzQRoq96M663zo7HO_+smCt2f8JC7spDveXx4_+WUcdwXzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions (Isaac Morland <isaac.morland@gmail.com>) |
Ответы |
Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
|
Список | pgsql-hackers |
On Thu, 6 Jun 2024 at 20:10, Isaac Morland <isaac.morland@gmail.com> wrote: > > On Thu, 6 Jun 2024 at 12:53, Jeff Davis <pgsql@j-davis.com> wrote: > >> >> > I didn't get you completely here. w.r.t extensions how will this have >> > an impact if we set the search_path for definer functions. >> >> If we only set the search path for SECURITY DEFINER functions, I don't >> think that solves the whole problem. > > > Indeed. While the ability for a caller to set the search_path for a security definer functions introduces security problemsthat are different than for security invoker functions, it's still weird for the behaviour of a function to dependon the caller's search_path. It’s even weirder for the default search path behaviour to be different depending on whetheror not the function is security definer. +1 And +1 to the general idea and direction this thread is going in. I definitely think we should be making extensions more secure by default, and this is an important piece of it. Even by default making the search_path "pg_catalog, pg_temp" for functions created by extensions would be very useful.
В списке pgsql-hackers по дате отправления: