Search Postgresql Archives

dump/restore problem due to CVE-2018-1058 (9.5.12)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux