Re: Extension security improvement: Add support for extensions with an owned schema
От
Jelte Fennema-Nio
Тема
Re: Extension security improvement: Add support for extensions with an owned schema
Дата
Msg-id
CAGECzQSyznMQCPtrxn0FcnR3gS1pirt--Gw28to22Q+QMvDSVg@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Extension security improvement: Add support for extensions with an owned schema Jelte Fennema-Nio <me@jeltef.nl>
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 "David E. Wheeler" <david@justatheory.com>
Re: Extension security improvement: Add support for extensions with an owned schema Jelte Fennema-Nio <me@jeltef.nl>
Re: Extension security improvement: Add support for extensions with an owned schema Tom Lane <tgl@sss.pgh.pa.us>
Re: Extension security improvement: Add support for extensions with an owned schema Jelte Fennema-Nio <me@jeltef.nl>
Re: Extension security improvement: Add support for extensions with an owned schema "David E. Wheeler" <david@justatheory.com>
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 Marco Slot <marco.slot@gmail.com>
Re: Extension security improvement: Add support for extensions with an owned schema Jeff Davis <pgsql@j-davis.com>
Re: Extension security improvement: Add support for extensions with an owned schema Jelte Fennema-Nio <me@jeltef.nl>
Re: Extension security improvement: Add support for extensions with an owned schema Jelte Fennema-Nio <me@jeltef.nl>
Re: Extension security improvement: Add support for extensions with an owned schema "David G. Johnston" <david.g.johnston@gmail.com>
Re: Extension security improvement: Add support for extensions with an owned schema Jelte Fennema-Nio <me@jeltef.nl>
Re: Extension security improvement: Add support for extensions with an owned schema Tomas Vondra <tomas@vondra.me>
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 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. 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 [1]). 2. To make it easy for extension authors to avoid conflicts with other extensions/UDFs. > Perhaps with a control file setting to specify a > list of trusted extensions which we're also allowed to reference? I think we could simply use the already existing "requires" field from the control file. i.e. you're allowed to reference only your own extension > 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/catalog/namespace.c, every time we loop over activeSearchPath and CurrentExtensionObject is set, then we should skip any item that's not stored in pg_catalog, unless there's a DEPENDENCY_EXTENSION pg_depend entry for the item (and that pg_depend entry references the extension or the requires list). There's quite a few loops over activeSearchPath in namespace.c, but they all seem pretty similar. So while a bunch of code would need to be changed, the changes could probably be well encapsulated in a function. [1]: https://www.postgresql.org/message-id/flat/00d8f046156e355ec0eb49585408bafc8012e4a5.camel%40j-davis.com#3ad66667a8073d5ef50cfe44e305c38d
В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата: