From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | "Igal (at) Lucee(dot)org" <igal(at)lucee(dot)org> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_dump and search_path |
Date: | 2019-07-09 15:59:09 |
Message-ID: | CAKFQuwZ9xGQF=QTPUKUNoco9fjmM9WruCaDh5AmDc-RwQop0Cw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jul 9, 2019 at 8:48 AM Igal @ Lucee.org <igal(at)lucee(dot)org> wrote:
> David,
>
> On 7/9/2019 7:49 AM, David G. Johnston wrote:
>
> On Tue, Jul 9, 2019 at 7:41 AM Igal @ Lucee.org <igal(at)lucee(dot)org> wrote:
>
>> search_path is not set int he config, but rather with ALTER DATABASE SET
>> search_path TO ... but I have executed that prior to the RESTORE on the
>> target database. Would it make a difference if I set it in the config?
>>
>
> What is your restore command then? Because if you are dropping and
> recreating the same named database the ALTER DATABASE SET command is going
> to be lost with the drop since it is associated to an OID and not just the
> name. By placing the search_path into postgres.conf you avoid that issue
> altogether.
>
> The restore command is:
>
> pg_restore.exe --verbose --single-transaction -h <ip> -p <port> -d
> <dbname> -U postgres <path-to-pgdump-file>
>
> But how will I avoid the issue if the command `SELECT
> pg_catalog.set_config('search_path', '', false);` is part of the pgdump
> file? Wouldn't that override the config file setting during the restore
> process?
>
Yes, you are correct. I should have waited to respond to that point until
I was more woke.
> But, yes, objects saved to the database should usually have schema
> qualifications (which gets a bit messy with custom operators). search_path
> reliance should probably be reserved to interactive use or at worse client
> supplied queries.
>
> In my case I use a separate Postgres cluster for each database and the
> roles, absent of any successful hacking, are all limited to trusted users,
> so the risk mentioned in the CVE is non-existent and it would be great if
> there was an option to turn off that "feature".
>
This has been discussed a number of times shortly after the fix was
released. I'm of generally the same mind but no one of both mind and
capability has come forth and proposed a patch. IIRC there wasn't a
conclusive "we don't want this" so an implementation to discuss would at
least not be a foregone waste of time.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | John Lumby | 2019-07-09 17:31:00 | Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR |
Previous Message | Igal @ Lucee.org | 2019-07-09 15:48:44 | Re: pg_dump and search_path |