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 1tKmIt-00AiLB-0V for pgsql-general@arkaria.postgresql.org; Mon, 09 Dec 2024 22:32:35 +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 1tKmIq-00C9Y6-9K for pgsql-general@arkaria.postgresql.org; Mon, 09 Dec 2024 22:32:33 +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 1tKmIp-00C9Xy-Pg for pgsql-general@lists.postgresql.org; Mon, 09 Dec 2024 22:32:33 +0000 Received: from mail-oo1-xc2f.google.com ([2607:f8b0:4864:20::c2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tKmIo-001yWG-Cm for pgsql-general@postgresql.org; Mon, 09 Dec 2024 22:32:31 +0000 Received: by mail-oo1-xc2f.google.com with SMTP id 006d021491bc7-5f2b80b8e53so557106eaf.3 for ; Mon, 09 Dec 2024 14:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733783549; x=1734388349; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KXLstP5QmYIgIXnS7Zg5HtbB8CmTeC1iD+5pxR9Nkh8=; b=bYXTCGHfnPAo/Yx9quEtgVQcdRW7pVWuW9HxkBkVOrXXNrmdAPT448EqHWUf4Z7wB4 uFebpHOorilSYsMKdNpQZ42ybtiygeaggSHyx6aK7sBQtw90ceAXXI8Fq0txq4qDHJK6 SF/KYOLgNAkFx9ueCwMXEl9i4Ocq0LUITfNaSLboigIz+tLv6rP+Sq18MF5EA6tHPO3r s/43fW0bm1F8DtQZ0XV2f9psiDEbiGEEW7xfIMFgJz4c6tmH59kU9rQeQR2z7xRjp218 VvfGI9nyLY+496jBU2Y9VLA+E+c7Bw4JK2F1Mbkmrdle8jASmuebhTAdaaJme/6wLDu2 bhAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733783549; x=1734388349; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KXLstP5QmYIgIXnS7Zg5HtbB8CmTeC1iD+5pxR9Nkh8=; b=tHCc2l6SWBqH3aINLlfveAfYYA7GqPthjemSDM9Jd5r+PDD6z0nvqiQvHyypQ3LkTk n4Lx1Y9yrabo7/QLL1ROR5A9EFLnPaMRXhgyKxUs9SR/NcrTUW7CTmLenKVrg4nXzlTC zpdRwUss8D6UpHAapt83aSj3VL8yMcsws6BZLQd38venIusug6/nL25O0sB/HLhUkpGB JDXII/QIudSEJeK3VTcjW2Ht9KbGfLBMAXdPk9io3LN5lW7CsnGWgIsj2MpV0ljf1BbQ zd7DkMsonEgmCjjzPvz++DBopkPL6wWucILSbMj2n6fYeO4F/GLDhYI5+5GzhiSFgasy dYLg== X-Forwarded-Encrypted: i=1; AJvYcCXPf73EVcoy8wc0n1m3J9qg6Fo6NbxAgxQLH7IcfWzDXISVNSyXy5nY27TmJxcTFpZjMBZKlJKx7FvX81Qx@postgresql.org X-Gm-Message-State: AOJu0Yz6t6fFdFnDlIzG96EHHzDglCjEvg5Bv1+vJp9UjfvJGYTos3bF bI6Ll+CKVfYD4kZCmX/mjYFaKiFx4W1QL4R3T3Nqxr6QN/NfwxLVtuaxOgyUvEH3hhH/xFwsmNd 8KDcleSut72Rjg9BHuqOYhx40C8Q= X-Gm-Gg: ASbGncuCN+wCexXbwfKh9IDmDnLRFFO3fe0fhL7eEgXDyQur5QcczxE7RxCbUzg76et glRsV0SI2WUlEhPthmSU6ZKMTOrPz9pHTHsM= X-Google-Smtp-Source: AGHT+IGAQ9THthfRsb8tkKI8BYFEWMwWq7zo9X3QGvmwrkccQesOQBiFDorcW9PgOVSTLqlORc3Af6R24Ojk26f8yiA= X-Received: by 2002:a05:6820:1c9e:b0:5e5:b652:9d14 with SMTP id 006d021491bc7-5f2c8bc94f9mr1375900eaf.1.1733783549492; Mon, 09 Dec 2024 14:32:29 -0800 (PST) MIME-Version: 1.0 References: <6a6439f1-8039-44e2-8fb9-59028f7f2014@mailbox.org> <9c5ba566-27b8-4e8c-bf7d-2dc561509991@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> In-Reply-To: <9a7ca237-7696-40e3-9ae6-12bd98c1b86c@mailbox.org> From: "David G. Johnston" Date: Mon, 9 Dec 2024 15:31:52 -0700 Message-ID: Subject: Re: Errors when restoring backup created by pg_dumpall To: PopeRigby Cc: Adrian Klaver , Tom Lane , "pgsql-general@postgresql.org" Content-Type: multipart/alternative; boundary="00000000000095c4920628ddf06d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000095c4920628ddf06d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 9, 2024 at 3:14=E2=80=AFPM PopeRigby wr= ote: > On 12/7/24 11:58, David G. Johnston wrote: > > On Sat, Dec 7, 2024 at 12:25=E2=80=AFPM 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 th= e > generated expression with a custom function and in that custom function's > create function command attach a "set search_path to public" clause. Tha= t > will prevent inlining and also ensure the public schema is in the > search_path when executing the public.ll_to_earth function call. With th= at > 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. --00000000000095c4920628ddf06d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2024 at 3:14=E2=80=AFPM PopeRigby <poperigby@mailbox.org> wrote:
=20 =20 =20
On 12/7/24 11:58, David G. Johnston wrote:
=20
On Sat, Dec 7, 2024 at 12:25=E2=80=AFPM 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 yo= u mean "get it to put public there" (i.e., the "no= t" is a typo)

You cannot.= =C2=A0 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 "se= t search_path to public" clause.=C2=A0 That will prevent inl= ining and also ensure the public schema is in the search_path when executing the public.ll_to_earth function call.=C2=A0 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 t= he work being done "upstream" to fix the situation.=C2=A0 It'= s a big knot in the system and it isn't easy (or highly motivated) to u= ntangle unfortunately...

David J.

--00000000000095c4920628ddf06d--