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

From Ashutosh Sharma
Subject Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date
Msg-id CAE9k0PmnCYr2up8KaCRJp7yV4QQA==wLKOi5kcFfXOTX-FQMJg@mail.gmail.com
Whole thread Raw
In response to Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
List pgsql-hackers
Hi Jeff,

On Wed, Jun 12, 2024 at 3:07 AM Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Tue, 2024-06-11 at 15:24 +0530, Ashutosh Sharma wrote:
> > 3) When the ALTER EXTENSION SET SCHEMA command is executed and if the
> > function's search_path contains the old schema of the extension, it
> > is
> > updated with the new schema.
>
> I don't think it's reasonable to search-and-replace within a function's
> SET clause at ALTER time.
>
> I believe we need a new special search_path item, like
> "$extension_schema", to mean the schema of the extension owning the
> function. It would, like "$user", automatically adjust to the current
> value when changed.
>
> That sounds like a useful and non-controversial change.

I've definitely thought about it, and I agree that this approach could
help simplify things. However, we do have some challenges with the
resolution of $extension_schema variable compared to $user. Firstly,
we need something like CurrentExtensionId to resolve
$extension_schema, and we need to decide where to manage it
(CurrentExtensionId). From what I understand, we should set
CurrentExtensionId when we're getting ready to execute a function, as
that's when we recompute the namespace path. But to set
CurrentExtensionId at this point, we need information in pg_proc to
distinguish between extension-specific and non-extension functions. If
it's an extension specific function, it should have the extension OID
in pg_proc, which we can use to find the extension's namespace and
eventually resolve $extension_schema. So, to summarize this at a high
level, here's is what I think can be done:

1) Include extension-specific details, possibly the extension OID, for
functions in pg_proc during function creation.

2) Check if a function is extension-specific while preparing for
function execution and set CurrentExtensionId accordingly.

3) Utilize CurrentExtensionId to resolve the namespace path during
recomputation.

4) Above steps will automatically repeat if the function is nested.

5) Upon completion of function execution, reset CurrentExtensionId to
InvalidOid.

I think this should effectively tackle the outlined challenges with
resolution of $extension_schema during namespace path recomputation.
What are your thoughts on it?

Thanks,

--
With Regards,
Ashutosh Sharma.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: confirmed flush lsn seems to be move backward in certain error cases
Next
From: Ashutosh Sharma
Date:
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions