On Thu, Jun 6, 2024 at 2:36 AM Jeff Davis <pgsql@j-davis.com> wrote:
On Wed, 2024-06-05 at 14:36 +0530, Ashutosh Sharma wrote: > Thank you, Ashutosh, for the quick response. I've drafted a patch > aimed at addressing this issue. The patch attempts to solve this > issue by configuring the search_path for all security definer > functions created by the extension.
I like the general direction you propose, but I think it needs more discussion about the details.
I agree.
* What exactly is the right search_path for a function defined in an extension?
Determining the precise value can be challenging. However, since it's a function installed by an extension, typically, the search_path should include the extension's search_path and the schema where the function resides. If the function relies on a schema other than the one we set in its search_path, which would usually be the one created by the extension, this approach will enforce the extension developers to set the extension's specific search_path in the create function statement, if it's not set. The primary goal here is to ensure that the security definer functions created by an extension do not refer to any untrusted schema(s).
* Do we need a new magic search_path value of "$extension_schema" that resolves to the extension's schema, so that it can handle ALTER EXTENSION ... SET SCHEMA?
Possibly yes, we can think about it, I think it would be something like the $user we have now.
* What do we do for functions that want the current behavior and how do we handle migration issues?
That can be controlled via some GUC if needed, I guess.
* What about SECURITY INVOKER functions? Those can still be vulnerable to manipulation by the caller by setting search_path, which can cause an incorrect value to be returned. That can matter in some contexts like a CHECK constraint.
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.
