Remove hard dependency on creation in the pg_catalog schema
#289
Conversation
|
As far as I know this change was made because of security reasons. Placing an extension in an already existing schema can cause a lot of trickery with search_path to have extensions execute unintended code with high permissions. I don't think this added security layer is worth breaking upgrades though. |
| @@ -2,4 +2,3 @@ comment = 'Job scheduler for PostgreSQL' | |||
| default_version = '1.6' | |||
| module_pathname = '$libdir/pg_cron' | |||
| relocatable = false | |||
| schema = pg_catalog | |||
There was a problem hiding this comment.
To be honest, I don't think this is an acceptable change. This is likely to cause privilege escalation issues on platforms that allow regular users to create the extension, but deliberately do not provide superuser access.
There was a problem hiding this comment.
Maybe if we do a very careful audit:
e.g. the unqualified nextval default in
https://github.com/citusdata/pg_cron/blob/main/pg_cron--1.2--1.3.sql looks dodgy
(It's easy to miss things)
can you clarify the scenarios that break? it's worth noting that pg_dump & pg_restore has never worked due to #113 |
|
Why was this closed without being merged? It's a breaking and undocumented change. Our Terraform is now breaking and can't create a database in GCP CloudSQL due to this. |
Users were able to create the extension on any schema on versions earlier than 1.5. At version 1.5 we started to force users to create the extension in
pg_catalog. This set of events cause hardship when doing a pg_dump&pg_restore.Fixes: #274