Re: Extension security improvement: Add support for extensions with an owned schema - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Extension security improvement: Add support for extensions with an owned schema
Date
Msg-id CAOBaU_YTJwo=jevDDKXRjwFUqON2VoWqz=Aw0FedyxbfYSiisw@mail.gmail.com
Whole thread Raw
In response to Re: Extension security improvement: Add support for extensions with an owned schema  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Extension security improvement: Add support for extensions with an owned schema
List pgsql-hackers
On Tue, 12 Aug 2025, 03:24 Robert Haas, <robertmhaas@gmail.com> wrote:
On Mon, Aug 11, 2025 at 1:55 PM Robert Haas <robertmhaas@gmail.com> wrote:
> [ some review ]

Another thing that's occurring to me here is that nothing prevents
other objects from making their way into the owned schema. Sure, if we
create a new schema with nobody having any permissions, then only the
creating role or some role that has its privileges can add anything in
there. But that could happen by accident, or privileges could later be
granted and somebody could add something into the extension schema
after that. I wonder whether we should lock this down tighter somehow
and altogether forbid creating objects in that schema except from an
extension create/upgrade script for the owning extension.

I think that it would be too strict. One not too uncommon scenario is an extension in a dedicated schema that creates additional objects dynamically, for instance creating new partitions using triggers on one of the extension table.  Such objects are not part of the extension and yet are in control of the extension.

As an example powa already relies on that a lot (it creates new tables if you register a new extension dynamically), and I'm about to add a feature that create/drops s a bunch of inherited tables via a trigger when a remote server is added / removed. I'm sure that there are a lot of other extensions doing something similar. 

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Replace magic numbers with strategy numbers for B-tree indexes
Next
From: Richard Guo
Date:
Subject: Re: MergeAppend could consider sorting cheapest child path