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
