Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tKmLD-00AiXz-QC for pgsql-general@arkaria.postgresql.org; Mon, 09 Dec 2024 22:35:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tKmLB-00CErD-5I for pgsql-general@arkaria.postgresql.org; Mon, 09 Dec 2024 22:34:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tKmLA-00CEqy-Ia for pgsql-general@lists.postgresql.org; Mon, 09 Dec 2024 22:34:58 +0000 Received: from mout-p-202.mailbox.org ([2001:67c:2050:0:465::202]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tKmL8-001yXh-Qi for pgsql-general@postgresql.org; Mon, 09 Dec 2024 22:34:56 +0000 Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4Y6c9y2lNsz9sbL; Mon, 9 Dec 2024 23:34:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1733783686; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CBTNlMxDcaB4F5SDwl5S0OxNLEgg3Paf4GIhKFiyAh8=; b=S9ux+Cd8PogahGnvuppC8SECjdgyX9REqUXgjl0Oq02E1Jx3Ty2/+czLSIq6W4N5/7O60E kXAuDDqOwlbWyouQY8VWchjXI/2RgFN5wOYCYhbc5vRu9n8SetbrT+u0qk4fBqBW4kKYZ0 FMpHXjizNB1nqpKnAthGWUiMWqAXxpU6n7amIK6gCB2BRZ41DqNfZ0mFsRnqTEUyzx5Ka3 AgbBprzmyvMJPBdUrh7v0JdlnvRUK/n59UnNer2v0NDf1HUqTmI8BeEXgzhJVZbj7DfRbe GAC+ke1pNYEyhtp+6nafA8WOLdv0wLv70k610TzXItgQkokV2GtBYxcM4Io0rA== Content-Type: multipart/alternative; boundary="------------9Zw9SYpckxhB54cVL1JEtKbe" Message-ID: Date: Mon, 9 Dec 2024 14:34:27 -0800 MIME-Version: 1.0 Subject: Re: Errors when restoring backup created by pg_dumpall To: "David G. Johnston" Cc: Adrian Klaver , Tom Lane , "pgsql-general@postgresql.org" References: <6a6439f1-8039-44e2-8fb9-59028f7f2014@mailbox.org> <41791b6d-aaf5-4fed-9cc3-e89bc49e8637@mailbox.org> <1257068.1733025493@sss.pgh.pa.us> <06425038-e012-4bac-aec1-d9541436f893@mailbox.org> <92405f98-7f0c-4442-8252-697352daefc1@aklaver.com> <1470486.1733087658@sss.pgh.pa.us> <4ab662d8-57cc-471f-8a58-cfd71d1cea22@aklaver.com> <1475512.1733090108@sss.pgh.pa.us> <19d5f2c7-1252-4442-accb-8aa2cb289ad0@mailbox.org> <9a7ca237-7696-40e3-9ae6-12bd98c1b86c@mailbox.org> Content-Language: en-US From: PopeRigby In-Reply-To: X-MBO-RS-META: 9d83hyyegpncasnxiqbegc9m458xhj6c X-MBO-RS-ID: 7c37afea27016d03fbc List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------9Zw9SYpckxhB54cVL1JEtKbe Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/9/24 14:31, David G. Johnston wrote: > On Mon, Dec 9, 2024 at 3:14 PM PopeRigby wrote: > > On 12/7/24 11:58, David G. Johnston wrote: >> On Sat, Dec 7, 2024 at 12:25 PM PopeRigby >> wrote: >> >> >> It actually looks like setting those all to have public fixed >> all the >> errors, including the one with lldap. So, how can I get it to >> not put >> public there automatically for next time? >> >> >> I assume you mean "get it to put public there" (i.e., the "not" >> is a typo) >> >> You cannot.  The security team has decided to not permit an >> opt-in bypass of the lock-downs implemented to fix CVE-2018-1058. >> >> Your only real choice at the moment is to replace the function >> call in the generated expression with a custom function and in >> that custom function's create function command attach a "set >> search_path to public" clause.  That will prevent inlining and >> also ensure the public schema is in the search_path when >> executing the public.ll_to_earth function call.  With that in >> place the empty search_path in the dump file will no longer matter. >> > Yeah, that was a typo. It seems weird that this behavior would be > broken by default though, is there anything that could fix it > upstream? > > > You saw and tried the work being done "upstream" to fix the situation. > It's a big knot in the system and it isn't easy (or highly motivated) > to untangle unfortunately... > > David J. > Understood. Well, at least it was a fairly easy fix. Thanks for the help :) --------------9Zw9SYpckxhB54cVL1JEtKbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/9/24 14:31, David G. Johnston wrote:
On Mon, Dec 9, 2024 at 3:14 PM PopeRigby <poperigby@mailbox.org> wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <poperigby@mailbox.org> wrote:

It actually looks like setting those all to have public fixed all the
errors, including the one with lldap. So, how can I get it to not put
public there automatically for next time?


I assume you mean "get it to put public there" (i.e., the "not" is a typo)

You cannot.  The security team has decided to not permit an opt-in bypass of the lock-downs implemented to fix CVE-2018-1058.

Your only real choice at the moment is to replace the function call in the generated expression with a custom function and in that custom function's create function command attach a "set search_path to public" clause.  That will prevent inlining and also ensure the public schema is in the search_path when executing the public.ll_to_earth function call.  With that in place the empty search_path in the dump file will no longer matter.

Yeah, that was a typo. It seems weird that this behavior would be broken by default though, is there anything that could fix it upstream?


You saw and tried the work being done "upstream" to fix the situation.  It's a big knot in the system and it isn't easy (or highly motivated) to untangle unfortunately...

David J.

Understood. Well, at least it was a fairly easy fix. Thanks for the help :)

--------------9Zw9SYpckxhB54cVL1JEtKbe--