Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Поиск
Список
Период
Сортировка
От Ashutosh Sharma
Тема Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Дата
Msg-id CAE9k0PmnCYr2up8KaCRJp7yV4QQA==wLKOi5kcFfXOTX-FQMJg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: confirmed flush lsn seems to be move backward in certain error cases
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions