MIME-Version: 1.0
References: 
 <CAGECzQQzDqDzakBkR71ZkQ1N1ffTjAaruRSqppQAKu3WF+6rNQ@mail.gmail.com>
 <dbd3cc5a5edde04941c8624dde7e4bd2a063f366.camel@j-davis.com>
 <CAGECzQTe3y6xwP9aMbFBCxKnQEEn3G3=cEDqoD5xaOwPwypd_A@mail.gmail.com>
 <CAGECzQTAgtTp3G=Em3xEY=T=uiKfyu5xLYri9By=sfNBS5C_9A@mail.gmail.com>
 <CAKFQuwaT4_n=e0YKBZAyox1CQUra2ka0cySs+3pGZR5p50pn-g@mail.gmail.com>
 <CAGECzQTOJrnnJkmMe9nems0jouiKUbFcEb1rb9kE_svsAZiGQg@mail.gmail.com>
 <585e996c-a5c6-4e61-acc4-d92b7a1458ea@vondra.me>
 <CAGECzQS02M6YPDXemo36tShO-ZYObjqnyTJyVttua1PGyN4xRw@mail.gmail.com>
 <CAFPkQKzALOTTBrhj2qDHwVxZQyjF5Xg_P9M=Tn_Dcm3vr=xdTA@mail.gmail.com>
 <DBOFQN54M5FX.1XWJE4LKMR8XH@jeltef.nl>
 <CA+TgmoY=NO7_L=UDuoUWj-icABF-7EP=UNUXCFBYpDNFoUZmbA@mail.gmail.com>
 <CA+TgmoYDdYA1paUKtfHfx-iDdCKrL05m2OwPHz7SQ03t49f2oQ@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoYDdYA1paUKtfHfx-iDdCKrL05m2OwPHz7SQ03t49f2oQ@mail.gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
Date: Tue, 2 Sep 2025 08:03:04 +0800
Message-ID: 
 <CAOBaU_YTJwo=jevDDKXRjwFUqON2VoWqz=Aw0FedyxbfYSiisw@mail.gmail.com>
Subject: Re: Extension security improvement: Add support for extensions with
 an owned schema
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>,
 Artem Gavrilov <artem.gavrilov@percona.com>,
	Jelte Fennema-Nio <me@jeltef.nl>, Tomas Vondra <tomas@vondra.me>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
 Jeff Davis <pgsql@j-davis.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000002aaa3063dc637a0"
Archived-At: 
 <https://www.postgresql.org/message-id/CAOBaU_YTJwo%3DjevDDKXRjwFUqON2VoWqz%3DAw0FedyxbfYSiisw%40mail.gmail.com>
Precedence: bulk

--00000000000002aaa3063dc637a0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 12 Aug 2025, 03:24 Robert Haas, <robertmhaas@gmail.com> wrote:

> On Mon, Aug 11, 2025 at 1:55=E2=80=AFPM Robert Haas <robertmhaas@gmail.co=
m> 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.

>

--00000000000002aaa3063dc637a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, 12 Aug 2025, 03:24 Robert Haas, =
&lt;<a href=3D"mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, A=
ug 11, 2025 at 1:55=E2=80=AFPM Robert Haas &lt;<a href=3D"mailto:robertmhaa=
s@gmail.com" target=3D"_blank" rel=3D"noreferrer">robertmhaas@gmail.com</a>=
&gt; wrote:<br>
&gt; [ some review ]<br>
<br>
Another thing that&#39;s occurring to me here is that nothing prevents<br>
other objects from making their way into the owned schema. Sure, if we<br>
create a new schema with nobody having any permissions, then only the<br>
creating role or some role that has its privileges can add anything in<br>
there. But that could happen by accident, or privileges could later be<br>
granted and somebody could add something into the extension schema<br>
after that. I wonder whether we should lock this down tighter somehow<br>
and altogether forbid creating objects in that schema except from an<br>
extension create/upgrade script for the owning extension.<br></blockquote><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I think that it wo=
uld be too strict. One not too uncommon scenario is an extension in a dedic=
ated schema that creates additional objects dynamically, for instance creat=
ing new partitions using triggers on one of the extension table.=C2=A0 Such=
 objects are not part of the extension and yet are in control of the extens=
ion.</div><div dir=3D"auto"><br></div><div dir=3D"auto">As an example powa =
already relies on that a lot (it creates new tables if you register a new e=
xtension dynamically), and I&#39;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&#39;m sure that there are a lot of other extensions doing some=
thing similar.=C2=A0</div><div dir=3D"auto"><div class=3D"gmail_quote gmail=
_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div>

--00000000000002aaa3063dc637a0--