pg.ddx.io  pgsql-general@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Adrian Klaver <adrian.klaver@aklaver.com>
To: Rory Campbell-Lange <rory@campbell-lange.net>
To: pgsql-general@postgresql.org
Subject: Re: dump/restore problem due to CVE-2018-1058 (9.5.12)
Date: Sat, 7 Apr 2018 12:46:52 -0700
Message-ID: <a0dc9bf9-ef82-6f2c-b1f4-0087644981ba@aklaver.com> (raw)
In-Reply-To: <20180407192757.utugzd2zbwbtwoui@campbell-lange.net>
References: <20180407192757.utugzd2zbwbtwoui@campbell-lange.net>

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@aklaver.com




view thread (7+ messages)  latest in thread

Message-ID: <a0dc9bf9-ef82-6f2c-b1f4-0087644981ba@aklaver.com>
Permalink:  ../a0dc9bf9-ef82-6f2c-b1f4-0087644981ba@aklaver.com/
Also on:    postgresql.org/message-id/a0dc9bf9-ef82-6f2c-b1f4-0087644981ba@aklaver.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-general@postgresql.org
  Cc: adrian.klaver@aklaver.com, rory@campbell-lange.net
  Subject: Re: dump/restore problem due to CVE-2018-1058 (9.5.12)
  In-Reply-To: <a0dc9bf9-ef82-6f2c-b1f4-0087644981ba@aklaver.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox