Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
От | John H |
---|---|
Тема | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions |
Дата | |
Msg-id | CA+-JvFtkZ478qTpkFp=-HbhxiK4juOXqd-rG4GCvWg54AWAQkg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions (Ashutosh Sharma <ashu.coek88@gmail.com>) |
Ответы |
Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
|
Список | pgsql-hackers |
Hi Ashutosh, Thanks for clarifying. > not standalone functions created independently I'm wondering why we wouldn't want to extend that functionality so that if users (including superusers) do want to automatically configure search_path when they're creating functions it's available. > The difference is that installing extensions typically requires superuser privileges, > which is not the case with standalone functions. Yes, but inadvertent access to different roles can still occur even if it's not a superuser. It's not clear to me who the audience of this commit is aimed at, cause I see two sort of different use cases? 1. Make it easier for extension authors to configure search_path when creating functions The proposed mechanism via control file makes sense, although I would like to understand why specifying it today in CREATE FUNCTION doesn't work. Is it an awareness issue? I suppose it's easier if you only need to set it once in the control file? Is that ease-of-use what we want to solve? 2. Make it easier to avoid inadvertent escalations when functions are created (e.g CREATE EXTENSION/CREATE FUNCTION) Then I think it's better to provide users a way to force the search_path on functions when extensions are created so superusers aren't reliant on extension authors. Thanks, -- John Hsu - Amazon Web Services
В списке pgsql-hackers по дате отправления: