From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jelte Fennema-Nio <me(at)jeltef(dot)nl>, Artem Gavrilov <artem(dot)gavrilov(at)percona(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extension security improvement: Add support for extensions with an owned schema |
Date: | 2025-09-06 00:17:03 |
Message-ID: | aLt9f7u_jUnMgGOe@jrouhaud |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <rjuju123(at)gmail(dot)com> 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
> > plpgsql and work just fine.
> >
> > Why not requiring schema owner privileges?
>
> I agree with you that requiring superuser privileges is undesirable.
> However, requiring schema owner privileges isn't really requiring
> anything above and beyond what the permissions system would require
> anyway, since at the start, nobody else will have privileges on that
> schema. And that's where what Jelte was proposing -- and also what you
> propose here -- seems very accident-prone to me. It would be quite
> easy for the user who created the extension, and who therefore also
> owns the schema IIUC, to accidentally put other stuff there, or allow
> others to do so
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'm also wondering how much you can prevent the owner from doing changes in the
owned schema without leading to unhelpful behavior. Would the owner still be
allowed to create extra indexes on extension owned table for instance, change
the TOAST setting, move them to other tablespace or ...?
> The first thought that popped into my head was that maybe your
> extension should make the objects it creates part of the extension,
> but I think that doesn't actually work, because it would mean that
> they would not be dumped.
Arguably there is pg_extension_config_dump() for that, assuming that this would
become allowed in scenario like the one I described (and modified to also emit
the DDL in such case). But it would be hard for extension authors to use as
you would have to call it only with some major versions.
We could do it automatically, but extensions may not need to dump all tables
and/or all rows. For instance in powa we have some unlogged tables that are
use transiently during a snapshot, and those tables shouldn't be dumped. Right
now if such tables are created by the extension they're always dumped, but it
would be good to make it configurable if dynamically created tables become part
of the extension, one way or another.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-09-06 01:01:24 | Re: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c |
Previous Message | Masahiko Sawada | 2025-09-05 23:21:02 | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |