From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Jeremy Evans <code@jeremyevans.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Date: Sat, 08 Sep 2018 16:02:01 -0400
Message-ID: <6869.1536436921@sss.pgh.pa.us> (raw)
In-Reply-To: <3979.1536433320@sss.pgh.pa.us>
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>
<3979.1536433320@sss.pgh.pa.us>
I wrote:
> 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.
After groveling through all the FRONTEND conditionals in those
directories, it seems like indeed this is the first really obvious problem
that would ensue from libpq invoking the backend version of some common
function. There are some minor pecadilloes:
* "could not determine encoding" warning in chklocale.c might get printed
via ereport, not fprintf(stderr) as expected; but likely nobody would even
realize that was the wrong thing, and it's a very unlikely message anyway.
* getaddrinfo.c might use non-reentrant gethostbyname, but in the backend
environment that's hardly a problem due to lack of threading.
* thread.c might use non-reentrant strerror, getpwuid, gethostbyname,
but ditto.
* saslprep.c might ereport about password-too-long, which would be bad
(leading to leakage of a partially-built PGconn) but it's probably not
a case anybody would exercise in the field.
* scram_build_verifier might palloc instead of malloc, as might
unicode_norm.c. In some code paths I think that'd be OK because
the caller would also be backend code and would pfree not free,
but I think there are other paths where this is also a crash risk.
Still, these also are issues that are new with SCRAM support.
So the bottom line is that this theory does fit the observed facts.
Hence we need to make sure that version-script filtering happens on every
ELF-based platform, not just the most popular ones. I see that the
FreeBSD and NetBSD stanzas in Makefile.shlib also have "ifdef ELF_SYSTEM"
portions, so probably we need to put the version-script stuff into those
too. Anybody have thoughts about other possibly-affected platforms?
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>> Is this potentially also a problem for libpqwalreceiver, which also
>> loads libpq?
The proposed fix would make libpq OK in that context, but I'm now
wondering if libpqwalreceiver itself needs a version-script.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, code@jeremyevans.net, 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: <6869.1536436921@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox