From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
cc: Jeremy Evans <code@jeremyevans.net>,
 Michael Paquier <michael@paquier.xyz>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
In-reply-to: <87o9d8rv08.fsf@news-spur.riddles.org.uk>
References: <153626613985.23143.4743626885618266803@wrigleys.postgresql.org>
 <20180906215836.GP2726@paquier.xyz>
 <20180906222843.GF17425@jeremyevans.local>
 <20180907165103.GH17425@jeremyevans.local>
 <20180907175518.GI17425@jeremyevans.local>
 <20180907181522.GB32058@paquier.xyz> <20016.1536351535@sss.pgh.pa.us>
 <20180907204403.GC32058@paquier.xyz> <16558.1536407783@sss.pgh.pa.us>
 <18398.1536410055@sss.pgh.pa.us> <87o9d8rv08.fsf@news-spur.riddles.org.uk>
Comments: In-reply-to Andrew Gierth <andrew@tao11.riddles.org.uk>
	message dated "Sat, 08 Sep 2018 14:22:22 +0100"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <3835.1536433199.0@sss.pgh.pa.us>
Date: Sat, 08 Sep 2018 15:02:00 -0400
Message-ID: <3979.1536433320@sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3835.1536433199.1@sss.pgh.pa.us>

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Could it be that somehow, when libpq is loaded into the backend
>  Tom> address space as it is here, libpq winds up calling the backend's
>  Tom> copy of pg_saslprep rather than its own?

> Yes, that is a thing that happens with ELF-style shared libs when you
> dynamically load shared libraries that weren't linked with -Bsymbolic.

If true, that's potentially pretty disastrous, because *every* src/port
or src/common function that's used by libpq would be similarly subject
to replacement by its backend version, and every behavioral difference
between the frontend and backend coding would be a source of trouble.

However, the info I can find about this suggests that it's only relevant
for exported functions, not ones that are hidden by means of a
version-script.  Since libpq doesn't export pg_saslprep, this shouldn't
be happening?

But wait, this problem is being reported on OpenBSD.  I wonder whether
their linker behaves anything like Linux's ... hm, it looks like it
*is* the same linker.

I tried setting up a scram-auth-based postgres_fdw connection on
my RHEL6 box and forcing it through the questionable code path
by issuing a dummy ALTER USER MAPPING command from another session.
It worked fine, so the problem doesn't seem to be present on Linux.

Repeating the same thing on a nearby OpenBSD 6.0 image ... kaboom!
It fails exactly as Jeremy describes.  Furthermore, I can confirm
that the attached patch fixes it.

I wonder which other platforms we have that behave like this?
And how come we've not seen symptoms before?  It's hard to believe
that src/common/saslprep.c is the only thing libpq imports
that has FRONTEND-vs-not-FRONTEND behavior differences.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="openbsd-link.patch"; charset="us-ascii"
Content-ID: <3835.1536433199.2@sss.pgh.pa.us>
Content-Description: openbsd-link.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/Makefile.shlib b/src/Makefile.shlib
index 95b82a6..1555be3 100644
--- a/src/Makefile.shlib
+++ b/src/Makefile.shlib
@@ -149,6 +149,11 @@ ifeq ($(PORTNAME), openbsd)
     ifdef soname
       LINK.shared	+=3D -Wl,-x,-soname,$(soname)
     endif
+    BUILD.exports	=3D ( echo '{ global:'; $(AWK) '/^[^\#]/ {printf "%s;\n=
",$$1}' $<; echo ' local: *; };' ) >$@
+    exports_file	=3D $(SHLIB_EXPORTS:%.txt=3D%.list)
+    ifneq (,$(exports_file))
+      LINK.shared	+=3D -Wl,--version-script=3D$(exports_file)
+    endif
     SHLIB_LINK		+=3D -lc
   else
     LINK.shared		=3D $(LD) -x -Bshareable -Bforcearchive

------- =_aaaaaaaaaa0--