From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Jeremy Evans <code(at)jeremyevans(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
Date: | 2018-09-08 19:02:00 |
Message-ID: | 3979.1536433320@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
Attachment | Content-Type | Size |
---|---|---|
openbsd-link.patch | text/x-diff | 607 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-08 19:11:15 | Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables |
Previous Message | Bruce Momjian | 2018-09-08 17:36:48 | Re: BUG #15373: null / utf-8 |