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 обсуждение исходный текст |
Ответ на | 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
Re: Extension security improvement: Add support for extensions with an owned schema Re: Extension security improvement: Add support for extensions with an owned schema |
Список | pgsql-hackers |
On Wed, 19 Jun 2024 at 17:28, Robert Haas <robertmhaas@gmail.com> 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 по дате отправления: