Extension security improvement: Add support for extensions with an owned schema
От | Jelte Fennema-Nio |
---|---|
Тема | Extension security improvement: Add support for extensions with an owned schema |
Дата | |
Msg-id | CAGECzQQzDqDzakBkR71ZkQ1N1ffTjAaruRSqppQAKu3WF+6rNQ@mail.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 |
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 create functions or operators in that schema they can do all kinds of search_path confusion attacks if not every function and operator that is used in the script is schema qualified. While doing such schema qualification is possible, it relies on the author to never make a mistake in any of the sql files. And sadly humans have a tendency to make mistakes. 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 before creating the extension, and will be created during extension creation. This thus gives the extension author an easy way to use a safe search_path, while still allowing all objects to be grouped together in a schema. The implementation also has the pleasant side effect that the schema will be automatically dropped when the extension is dropped. One way in which certain extensions currently hack around the non-existence of this feature is by using the approach that pg_cron uses: Setting the schema to pg_catalog and running "CREATE SCHEMA pg_cron" from within the extension script. While this works, it's obviously a hack, and a big downside of it is that it doesn't allow users to choose the schema name used by the extension. PS. I have never added fields to pg_catalag tables before, so there's a clear TODO in the pg_upgrade code related to that. If anyone has some pointers for me to look at to address that one that would be helpful, if not I'll probably figure it out myself. All other code is in pretty finished state, although I'm considering if AlterExtensionNamespace should maybe be split a bit somehow, because owned_schema skips most of the code in that function.
Вложения
В списке pgsql-hackers по дате отправления: