On 04/07/2018 12:27 PM, Rory Campbell-Lange wrote:
Hi
Following an upgrade to 9.5.12, we cannot restore some of our databases
due to a schema qualification issue introduced in the new postgres
version of pg_dump.
Specifically, the problem line is the addition of :
SELECT pg_catalog.set_config('search_path', '', false);
to the header of the pg_dump output.
As a result, pg_restore now fails because we have some table constraints
that use functions which do not use public schema qualified table/column
references.
(I'm aware that the reasons behind the change made to the dump format
due to CVE-2018-1058 are set out here:
https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path)
Additionally we sometimes use search_path manipulations +
temporary_schema.function to test functions in production environments.
Having to qualify the schema of objects seems a retrogressive step, but
perhaps our usage is peculiar in this way.
AFAIK you can still do that or did I miss something?
Also, in a coding environment where object.attribute masking is a
feature of the language, as it is in python, this change seems obtuse.
My function in schema x can still mask a function in another schema y,
so the problem of function masking (if it is a problem) still exists.
Are talking Python external or internal to Postgres?
If internal, then plpythonu is an untrusted language and can only be
used by a superuser. If you are a superuser then there is host of other
things you could do to compromise security as well.
Thanks for any comments.
Regards
Rory
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
