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 по дате отправления:

Предыдущее
От: Jelte Fennema-Nio
Дата:
Сообщение: Re: ssl tests fail due to TCP port conflict
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions