Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Дата
Msg-id CAExHW5vhD2BeC0cpD_tmX64bAH9UNT2AsVOTdV641wvOdQUJ7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Ответы Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Список pgsql-hackers


On Wed, Jun 12, 2024 at 9:51 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
On Wed, Jun 12, 2024 at 9:35 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> 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.
>

Alternatively, we could leverage the extension dependency information
to determine whether the function is created by an extension or not.


That will be simpler. We do that sort of thing for identity sequences. So there's a precedent to do that kind of stuff. 
--
Best Wishes,
Ashutosh Bapat

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alena Rybakina
Дата:
Сообщение: Re: Vacuum statistics
Следующее
От: Alexander Kukushkin
Дата:
Сообщение: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions