Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date: 2024-06-12 06:43:56
Message-ID: CAExHW5vhD2BeC0cpD_tmX64bAH9UNT2AsVOTdV641wvOdQUJ7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 12, 2024 at 9:51 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
wrote:

> On Wed, Jun 12, 2024 at 9:35 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
> wrote:
> >
> > Hi Jeff,
> >
> > On Wed, Jun 12, 2024 at 3:07 AM Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Kukushkin 2024-06-12 07:11:03 Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Previous Message Alena Rybakina 2024-06-12 06:38:30 Re: Vacuum statistics