From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions |
Date: | 2024-06-05 21:06:11 |
Message-ID: | 340cd4a0c30b46a185e66b1c7e91535921137da8.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2024-06-05 21:15:53 | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Previous Message | Paul Jungwirth | 2024-06-05 20:57:40 | Re: SQL:2011 application time |