Hi All,
Here is the v4 patch with the following new changes:
1) Now allows users to explicitly set search_path to $extension_schema.
2) Includes updates to the documentation.
3) Adds comments where previously absent.
Note: The new control file parameter is currently named as "protected"
which
Hi Robert,
On Tue, Jul 16, 2024 at 9:40 PM Robert Haas wrote:
>
> On Tue, Jul 16, 2024 at 1:55 AM Ashutosh Sharma wrote:
> > Just to confirm, are you suggesting to remove the protected flag and
> > set the default search_path (as $extension_schema,) for all functions
> > within an extension wher
On Tue, Jul 16, 2024 at 1:55 AM Ashutosh Sharma wrote:
> Just to confirm, are you suggesting to remove the protected flag and
> set the default search_path (as $extension_schema,) for all functions
> within an extension where no explicit search_path is set?
No, I'm not saying that. In fact I'm no
Hi Robert.
On Mon, Jul 15, 2024 at 11:15 PM Robert Haas wrote:
>
> On Mon, Jul 15, 2024 at 8:05 AM Ashutosh Sharma wrote:
> > I've added these changes to restrict users from explicitly setting the
> > $extension_schema in the search_path. This ensures that
> > $extension_schema can only be set i
On Mon, 2024-07-15 at 16:04 -0400, Robert Haas wrote:
> Oh, I had the opposite idea: I wasn't proposing ignoring it. I was
> proposing making it work.
I meant: ignore $extension_schema if the search_path has nothing to do
with an extension. In other words, if it's in a search_path for the
session,
On Mon, Jul 15, 2024 at 2:33 PM Jeff Davis wrote:
> On Mon, 2024-07-15 at 13:44 -0400, Robert Haas wrote:
> > But ... why? I mean, what's the point of prohibiting that?
>
> Agreed. We ignore all kinds of stuff in search_path that doesn't make
> sense, like non-existent schemas. Simpler is better.
On Mon, 2024-07-15 at 13:44 -0400, Robert Haas wrote:
> But ... why? I mean, what's the point of prohibiting that?
Agreed. We ignore all kinds of stuff in search_path that doesn't make
sense, like non-existent schemas. Simpler is better.
Regards,
Jeff Davis
On Mon, Jul 15, 2024 at 8:05 AM Ashutosh Sharma wrote:
> I've added these changes to restrict users from explicitly setting the
> $extension_schema in the search_path. This ensures that
> $extension_schema can only be set implicitly for functions created by
> the extension when the "protected" fla
Hi Robert,
On Fri, Jul 12, 2024 at 9:02 PM Robert Haas wrote:
>
> On Mon, Jun 24, 2024 at 3:10 PM Jeff Davis wrote:
> > A special search_path variable "$extension_schema" would be a better
> > solution to this problem. We need something like that anyway, in case
> > the extension is relocated, s
On Mon, Jun 24, 2024 at 3:10 PM Jeff Davis wrote:
> A special search_path variable "$extension_schema" would be a better
> solution to this problem. We need something like that anyway, in case
> the extension is relocated, so that we don't have to dig through the
> catalog and update all the setti
On Tue, Jun 25, 2024 at 12:40 AM Jeff Davis wrote:
>
> On Wed, 2024-06-19 at 08:53 +0530, Ashutosh Sharma wrote:
> > For standalone functions, users can easily adjust the search_path
> > settings as needed. However, managing this becomes challenging for
> > functions created via extensions. Extens
On Wed, 2024-06-19 at 08:53 +0530, Ashutosh Sharma wrote:
> For standalone functions, users can easily adjust the search_path
> settings as needed. However, managing this becomes challenging for
> functions created via extensions. Extensions are relocatable, making
> it difficult to determine and a
Hi,
On Wed, Jun 19, 2024 at 6:06 AM John H wrote:
>
> Hi Ashutosh,
>
> Thanks for clarifying.
>
> > not standalone functions created independently
>
> I'm wondering why we wouldn't want to extend that functionality so
> that if users (including superusers) do want to automatically
> configure sea
Hi Ashutosh,
Thanks for clarifying.
> not standalone functions created independently
I'm wondering why we wouldn't want to extend that functionality so
that if users (including superusers) do want to automatically
configure search_path
when they're creating functions it's available.
> The diff
Hi John,
On Tue, Jun 18, 2024 at 2:35 AM John H wrote:
>
> 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 th
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
inadvert
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.
v3-0001-Introduce-a-new-control-file-flag-called-protected-f.patch
Description: Binary data
Hi,
On Wed, Jun 12, 2024 at 11:35 PM John H wrote:
>
> > But, I also agree with Jelte, it should be a property of a control file,
> > rather than a user controlled parameter, so that an attacker can't opt out.
>
This will be addressed in the next patch version.
> +1. Also curious what happens
On Wed, 2024-06-12 at 15:36 -0400, Robert Haas wrote:
> But I think there's another problem, which is
> that if the extension is relocatable, how do you set a secure
> search_path? You could say SET search_path = foo, pg_catalog if you
> know the extension will be installed in schema foo, but if yo
On Wed, Jun 12, 2024 at 2:05 PM John H wrote:>
> I'm sympathetic to the problem of potential privilege escalation when
> executing functions. At the same time I'm not sure if there's that
> much of a difference between 'CREATE EXTENSION' vs superusers copying
> a series of 'CREATE FUNCTION' where
On Wed, 2024-06-12 at 12:13 +0530, Ashutosh Bapat wrote:
> > 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'
Hi,
> I know about the problem and have seen the original email.
I'm sympathetic to the problem of potential privilege escalation when
executing functions. At the same time I'm not sure if there's that
much of a difference between 'CREATE EXTENSION' vs superusers copying
a series of 'CREATE FUNC
Hi Ashutosh,
Apologies for any confusion, but I'm not entirely following your
> explanation. Could you kindly provide further clarification?
> Additionally, would you mind reviewing the problem description
> outlined in the initial email?
>
I know about the problem and have seen the original emai
On Wed, Jun 12, 2024 at 9:51 AM Ashutosh Sharma
wrote:
> On Wed, Jun 12, 2024 at 9:35 AM Ashutosh Sharma
> wrote:
> >
> > Hi Jeff,
> >
> > On Wed, Jun 12, 2024 at 3:07 AM Jeff Davis wrote:
> > >
> > > On Tue, 2024-06-11 at 15:24 +0530, Ashutosh Sharma wrote:
> > > > 3) When the ALTER EXTENSION
On Wed, Jun 12, 2024 at 9:35 AM Ashutosh Sharma wrote:
>
> Hi Jeff,
>
> On Wed, Jun 12, 2024 at 3:07 AM Jeff Davis 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 cont
Hi Jeff,
On Wed, Jun 12, 2024 at 3:07 AM Jeff Davis 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 ne
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 f
On Tue, 2024-06-11 at 14:56 +0200, Alexander Kukushkin wrote:
> Now attackers can just set search_path for the current session.
IIUC, the proposal is that only the function's "SET" clause can
override the behavior, not a top-level SET command.
Regards,
Jeff Davis
Hi Alexander,
On Tue, Jun 11, 2024 at 6:26 PM Alexander Kukushkin wrote:
>
> Hi,
>
> On Tue, 11 Jun 2024 at 14:50, Ashutosh Sharma wrote:
>>
>> If the author has configured the search_path for any desired function,
>> using this option with the CREATE EXTENSION command will not affect
>> those f
Hi,
On Tue, 11 Jun 2024 at 14:50, Ashutosh Sharma wrote:
> If the author has configured the search_path for any desired function,
> using this option with the CREATE EXTENSION command will not affect
> those functions.
>
Then effectively this feature is useless.
Now attackers can just set searc
Hi,
On Tue, Jun 11, 2024 at 5:02 PM Jelte Fennema-Nio wrote:
>
> On Tue, 11 Jun 2024 at 11:54, Ashutosh Sharma wrote:
> > 1) Extends the CREATE EXTENSION command to support a new option, SET
> > SEARCH_PATH.
>
>
> I don't think it makes sense to add such an option to CREATE EXTENSION.
> I feel l
On Tue, 11 Jun 2024 at 11:54, Ashutosh Sharma wrote:
> 1) Extends the CREATE EXTENSION command to support a new option, SET
> SEARCH_PATH.
I don't think it makes sense to add such an option to CREATE EXTENSION.
I feel like such a thing should be part of the extension control file
instead. That w
On Thu, Jun 6, 2024 at 2:36 AM Jeff Davis wrote:
>
> On Wed, 2024-06-05 at 14:36 +0530, Ashutosh Sharma wrote:
> > Thank you, Ashutosh, for the quick response. I've drafted a patch
> > aimed at addressing this issue. The patch attempts to solve this
> > issue by configuring the search_path for all
On Fri, 2024-06-07 at 00:19 +0200, Jelte Fennema-Nio wrote:
> Even by default making the search_path "pg_catalog, pg_temp" for
> functions created by extensions would be very useful.
Right now there's no syntax to override that. We'd need something to
say "get the search_path from the session".
R
On Thu, 6 Jun 2024 at 20:10, Isaac Morland wrote:
>
> On Thu, 6 Jun 2024 at 12:53, Jeff Davis wrote:
>
>>
>> > I didn't get you completely here. w.r.t extensions how will this have
>> > an impact if we set the search_path for definer functions.
>>
>> If we only set the search path for SECURITY DE
On Thu, 6 Jun 2024 at 12:53, Jeff Davis wrote:
> > I didn't get you completely here. w.r.t extensions how will this have
> > an impact if we set the search_path for definer functions.
>
> If we only set the search path for SECURITY DEFINER functions, I don't
> think that solves the whole problem
On Thu, 2024-06-06 at 21:17 +0530, Ashutosh Sharma wrote:
> That can be controlled via some GUC if needed, I guess.
That's a possibility, but it's easy to create a mess that way. I don't
necessarily oppose it, but we'd need some pretty strong agreement that
we are somehow moving users in a better
Hi,
On Thu, Jun 6, 2024 at 2:36 AM Jeff Davis wrote:
> On Wed, 2024-06-05 at 14:36 +0530, Ashutosh Sharma wrote:
> > Thank you, Ashutosh, for the quick response. I've drafted a patch
> > aimed at addressing this issue. The patch attempts to solve this
> > issue by configuring the search_path for
On Wed, 2024-06-05 at 14:36 +0530, Ashutosh Sharma wrote:
> Thank you, Ashutosh, for the quick response. I've drafted a patch
> aimed at addressing this issue. The patch attempts to solve this
> issue by configuring the search_path for all security definer
> functions created by the extension.
I l
On Fri, May 24, 2024 at 2:25 PM Ashutosh Bapat
wrote:
>
>
> On Fri, May 24, 2024 at 12:52 PM Ashutosh Sharma
> wrote:
>
>> Hi All,
>>
>> We all know that installing an extension typically requires superuser
>> privileges, which means the database objects it creates are owned by the
>> superuser.
On Fri, May 24, 2024 at 12:52 PM Ashutosh Sharma
wrote:
> Hi All,
>
> We all know that installing an extension typically requires superuser
> privileges, which means the database objects it creates are owned by the
> superuser.
>
> If the extension creates any SECURITY DEFINER functions, it can i
Hi All,
We all know that installing an extension typically requires superuser
privileges, which means the database objects it creates are owned by the
superuser.
If the extension creates any SECURITY DEFINER functions, it can introduce
security vulnerabilities. For example, consider an extension
42 matches
Mail list logo
