Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date
Msg-id 340cd4a0c30b46a185e66b1c7e91535921137da8.camel@j-davis.com
Whole thread Raw
In response to Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
List pgsql-hackers
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.

* What exactly is the right search_path for a function defined in an
extension?

* 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?

* What do we do for functions that want the current behavior and how do
we handle migration issues?

* 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.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Paul Jungwirth
Date:
Subject: Re: SQL:2011 application time
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs