On Sat, Sep 6, 2025 at 3:35 AM Jelte Fennema-Nio wrote:
> I think that sounds like reasonable change to Roberts initial
> proposal: Allowing the schema owner and superusers to add objects in
> the schema, but disallow all other users (even if they have CREATE
> privileges on the schema).
I don't
On Thu, Sep 11, 2025 at 9:29 AM Jelte Fennema-Nio wrote:
> You recall incorrectly ;) It only does that when you do:
> DROP EXTENSION ... CASCADE
>
> Otherwise you get errors like this:
>
> DROP EXTENSION test_ext_owned_schema;
> ERROR: cannot drop extension test_ext_owned_schema because other
>
On Thu, 11 Sept 2025 at 15:02, Robert Haas wrote:
> What the patch does (IIRC) is make it so that dropping the extension
> just cascade-drops the schema.
You recall incorrectly ;) It only does that when you do:
DROP EXTENSION ... CASCADE
Otherwise you get errors like this:
DROP EXTENSION test_
On Sat, 6 Sept 2025 at 02:17, Julien Rouhaud wrote:
> Requiring schema owner privilege wouldn't allow the user who created the
> extension to allow other users to mess up with the extension's private schema?
> At least not with a simple GRANT on the schema.
I think that sounds like reasonable cha
Hi,
On Tue, Sep 02, 2025 at 09:35:45AM -0400, Robert Haas wrote:
> On Tue, Sep 2, 2025 at 5:02 AM Julien Rouhaud wrote:
> > Requiring superuser permission seems like a big penalty, especially since
> > the
> > last few years have been all about *not* requiring superuser privileges.
> > Note
>
On Tue, 2 Sept 2025 at 02:03, Julien Rouhaud wrote:
> 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.
Interesting. I didn't know there were ext
On Tue, Sep 2, 2025 at 5:02 AM Julien Rouhaud wrote:
> Requiring superuser permission seems like a big penalty, especially since the
> last few years have been all about *not* requiring superuser privileges. Note
> also that not all extensions embeds compiled code, some are just doing plain
> plp
On Tue, Sep 02, 2025 at 09:37:31AM +0200, Jelte Fennema-Nio wrote:
> On Tue, 2 Sept 2025 at 02:03, Julien Rouhaud wrote:
> > One not too uncommon scenario is an extension in a dedicated schema that
> > creates additional objects dynamically, for instance creating new
> > partitions using trigger
On Tue, 12 Aug 2025, 03:24 Robert Haas, wrote:
> On Mon, Aug 11, 2025 at 1:55 PM Robert Haas 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 nobod
On Mon Aug 11, 2025 at 9:23 PM CEST, Robert Haas wrote:
On Mon, Aug 11, 2025 at 1:55 PM Robert Haas wrote:
[ some review ]
Attached is a patch that addresses your comments I think. I restructured
the schema creation code, and added more comments to the
AlterExtensionNamespace code (I couldn't
On Mon Sep 1, 2025 at 4:44 PM CEST, Jelte Fennema-Nio wrote:
On Mon Aug 11, 2025 at 9:23 PM CEST, Robert Haas wrote:
On Mon, Aug 11, 2025 at 1:55 PM Robert Haas wrote:
[ some review ]
Attached is a patch that addresses your comments I think.
Attached is a version that doesn't fail the tes
On Mon, Aug 11, 2025 at 1:55 PM Robert Haas 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 som
On Tue, Jul 29, 2025 at 5:35 AM Jelte Fennema-Nio wrote:
> On Wed Jul 23, 2025 at 7:12 PM CEST, Artem Gavrilov wrote:
> > 1) I noticed that pg_dump changes weren't covered with tests.
> >
> > 2) I assume these error messages may be confusing, especially first one:
>
> Attached is an updated versio
On Wed Jul 23, 2025 at 7:12 PM CEST, Artem Gavrilov wrote:
Hello Jelte,
1) I noticed that pg_dump changes weren't covered with tests.
2) I assume these error messages may be confusing, especially first one:
Attached is an updated version that addresses these issues.
From 7cc55c4e3a1fe2b5d958a
On Mon, 28 Jul 2025 at 00:03, Sadeq Dousti wrote:
> (a) The patch affects DROP EXTENSION in that it drops the schema as well, if
> it's owned by the extension. This needs to be mentioned in the documentation.
> In addition, an extra confirmation (e.g., "This will drop schema as
> well, do
You're absolutely right about the lack of interactivity. I'd still go with
your suggestion of using something along the lines of cascade/force, as
dropping the schema silently can potentially delete the user data.
Bests,
Sadeq
On Mon, Jul 28, 2025, 02:27 David G. Johnston
wrote:
> On Sunday, Ju
On Sunday, July 27, 2025, Sadeq Dousti wrote:
>
> (a) The patch affects DROP EXTENSION in that it drops the schema as well,
> if it's owned by the extension. This needs to be mentioned in the
> documentation. In addition, an extra confirmation (e.g., "This will drop
> schema as well, do you
Dear Jelte,
I like the idea! In fact, I was thinking about the general search_path
confusion issue in Postgres (see also [1]), and what the root cause is.
IMHO, some search paths should always take priority - e.g., if a function
is defined in both pg_catalog and as a UDF, the UDF should only be ca
Hello Jelte,
I reviewed your patch. Overall it looks good, I didn't find any problems
with code. Documentation is in place and clear.
Initial Run
===
The patch applies cleanly to HEAD (196063d6761). All tests successfully
pass.
Comments
===
1) I noticed that pg_dump changes weren
On Fri, 27 Sept 2024 at 14:00, Tomas Vondra wrote:
> One thing that's not quite clear to me is what's the correct way for
> existing extensions to switch to an "owned schema". Let's say you have
> an extension. How do you transition to this? Can you just add it to the
> control file and then some
Hi,
I've spent a bit of time looking at this patch. It seems there's a clear
consensus that having "owned schemas" for extensions would be good for
security. To me it also seems as a convenient way to organize stuff. It
was possible to create extensions in a separate schema before, ofc, but
that's
On Jun 19, 2024, at 13:50, Jelte Fennema-Nio wrote:
> This indeed does sound like the behaviour that pretty much every
> existing extension wants to have. One small addition/clarification
> that I would make to your definition: fully qualified references to
> other objects should still be allowed
On Jun 19, 2024, at 11:28, Robert Haas wrote:
> But I wonder if there might also be another possible approach: could
> we, somehow, prevent object references in extension scripts from
> resolving to anything other than the system catalogs and the contents
> of that extension? Perhaps with a contr
On Wed, Jun 19, 2024 at 1:50 PM Jelte Fennema-Nio wrote:
> I do think, even if we have this, there would be other good reasons to
> use "owned schemas" for extension authors. At least the following two:
> 1. To have a safe search_path that can be used in SET search_path on a
> function (see also [
On Wed, 19 Jun 2024 at 17:22, David G. Johnston
wrote:
>
> On Wed, Jun 19, 2024 at 8:19 AM Jelte Fennema-Nio wrote:
>
>>
>> Because part of it would
>> only be relevant once we support upgrading from PG18. So for now the
>> upgrade_code I haven't actually run.
>
>
> Does it apply against v16? If
On Wed, 19 Jun 2024 at 19:55, Tom Lane wrote:
>
> Jelte Fennema-Nio writes:
> > On Wed, 19 Jun 2024 at 17:28, Robert Haas wrote:
> >> I have a feeling that this might be pretty annoying to implement, and
> >> if that is true, then never mind.
>
> > Based on a quick look it's not trivial, but als
Jelte Fennema-Nio writes:
> On Wed, 19 Jun 2024 at 17:28, Robert Haas wrote:
>> I have a feeling that this might be pretty annoying to implement, and
>> if that is true, then never mind.
> Based on a quick look it's not trivial, but also not super bad.
> Basically it seems like in src/backend/ca
On Wed, 19 Jun 2024 at 17:28, Robert Haas wrote:
> But I wonder if there might also be another possible approach: could
> we, somehow, prevent object references in extension scripts from
> resolving to anything other than the system catalogs and the contents
> of that extension?
This indeed does
On Sat, Jun 1, 2024 at 8:08 PM Jelte Fennema-Nio wrote:
> Writing the sql migration scripts that are run by CREATE EXTENSION and
> ALTER EXTENSION UPDATE are security minefields for extension authors.
> One big reason for this is that search_path is set to the schema of the
> extension while runni
On Wed, Jun 19, 2024 at 8:19 AM Jelte Fennema-Nio wrote:
> Because part of it would
> only be relevant once we support upgrading from PG18. So for now the
> upgrade_code I haven't actually run.
>
Does it apply against v16? If so, branch off there, apply it, then upgrade
from the v16 branch to
Attached is an updated version of this patch that fixes a few issues
that CI reported (autoconf, compiler warnings and broken docs).
I also think I changed the pg_upgrade to do the correct thing, but I'm
not sure how to test this (even manually). Because part of it would
only be relevant once we s
On Wed, 5 Jun 2024 at 19:53, Jeff Davis wrote:
> Is this orthogonal to relocatability?
It's fairly orthogonal, but it has some impact on relocatability: You
can only relocate to a schema name that does not exist yet (while
currently you can only relocate to a schema that already exists). This
is
On Sat, 2024-06-01 at 17:08 -0700, Jelte Fennema-Nio wrote:
> This patch adds a new "owned_schema" option to the extension control
> file that can be set to true to indicate that this extension wants to
> own the schema in which it is installed. What that means is that the
> schema should not exist
On Sun, Jun 2, 2024, 02:08 Jelte Fennema-Nio wrote:
> This patch adds a new "owned_schema" option to the extension control
> file that can be set to true to indicate that this extension wants to
> own the schema in which it is installed.
Huge +1
Many managed PostgreSQL services block superuser a
Writing the sql migration scripts that are run by CREATE EXTENSION and
ALTER EXTENSION UPDATE are security minefields for extension authors.
One big reason for this is that search_path is set to the schema of the
extension while running these scripts, and thus if a user with lower
privileges can cr
35 matches
Mail list logo
