Re: Extension security improvement: Add support for extensions with an owned schema
От | Julien Rouhaud |
---|---|
Тема | Re: Extension security improvement: Add support for extensions with an owned schema |
Дата | |
Msg-id | aLt9f7u_jUnMgGOe@jrouhaud обсуждение исходный текст |
Ответ на | Re: Extension security improvement: Add support for extensions with an owned schema (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Extension security improvement: Add support for extensions with an owned schema
|
Список | 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@gmail.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.
В списке pgsql-hackers по дате отправления: