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)
We intend to change the schema qualifications in the check constraints
to work around this issue.
However I can't help but feel forcing the search_path to '' in pg_dump,
without a way that we can find for overriding it via setting, for
example, libpq environmental variables, is a rather odd constraint, as
when we load the backup as the postgres superuser. (I realise I can pipe
through sed or do something similar to fix this issue, but I don't see
why that is necessary).
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.
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.
Finally, if the point of the change was to make it less likely to allow
<general_schema>.<function> attacks then the mechanisms are already in
place to avoid that, namely the steps mentioned in the url above:
ALTER ROLE username SET search_path = "$user";
and
removing the default search_path setting postgresql.conf
and, most importantly
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
The permissions would therefore be at a policy level rather than what
seems like a bit of a cludge in pg_dump's output.
My apologies if I have missed the subtlety of the solution to the
problem, but allowing a normal user to write functions to public reminds
me of perl's Tom Christensen's famous reference to a "victimless crime".
In any event it probably *would* be good to not allow non-superusers to
mask a pg_catalog (or perhaps any other schema) function unless they
have a specific permission to do so. That is something I feel would be a
more useful solution to the security issue than only fiddling with the
public schema.
Thanks for any comments.
Regards
Rory
