Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
От | Ashutosh Sharma |
---|---|
Тема | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions |
Дата | |
Msg-id | CAE9k0PmnY+=mMLhz0o=G4_=U1CxQ_ORdos-y_Sde7mWTWTJ17w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
|
Список | pgsql-hackers |
Hi Robert. On Mon, Jul 15, 2024 at 11:15 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Mon, Jul 15, 2024 at 8:05 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > > I've added these changes to restrict users from explicitly setting the > > $extension_schema in the search_path. This ensures that > > $extension_schema can only be set implicitly for functions created by > > the extension when the "protected" flag is enabled. > > But ... why? I mean, what's the point of prohibiting that? In fact, > maybe we should have *that* and forget about the protected flag in the > control file. > Just to confirm, are you suggesting to remove the protected flag and set the default search_path (as $extension_schema,) for all functions within an extension where no explicit search_path is set? In addition to that, also allow users to explicitly set $extension_schema as the search_path and bypass resolution of $extension_schema for objects outside the extension? -- With Regards, Ashutosh Sharma.
В списке pgsql-hackers по дате отправления: