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

From John H
Subject Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date
Msg-id CA+-JvFtSp1L=7=46TgqMQrHD+6OSGqRh70A_6FSAWq01df2Qdg@mail.gmail.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
List pgsql-hackers
Hi Ashutosh,

Thinking about this more, could you clarify the problem/issue at hand?
I think it's still not clear to me.
Yes, CREATE EXTENSION can create functions that lead to unexpected
privilege escalation, regardless
 if they are SECURITY DEFINER or SECURITY INVOKER (if the function is
inadvertently executed by superuser).
But that's also true for a general CREATE FUNCTION call outside of extensions.

If I read the commit message I see:

> This flag controls PostgreSQL's behavior in setting the implicit
> search_path within the proconfig for functions created by an extension
> that does not have the search_path explicitly set in proconfig

If that's the "general" issue you're trying to solve, I would wonder
why we we wouldn't for instance be extending
the functionality to normal CREATE FUNCTION calls (ie, schema qualify
based off search_path)

Thanks,
John H

On Thu, Jun 13, 2024 at 1:09 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> Hi,
>
> Please find the attached patch addressing all the comments. I kindly
> request your review and feedback. Your thoughts are greatly
> appreciated.
>
> --
> With Regards,
> Ashutosh Sharma.



--
John Hsu - Amazon Web Services



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: FYI: LLVM Runtime Crash
Next
From: Melanie Plageman
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring