Teach libpq to handle arbitrary-length lines in .pgpass files.
authorTom Lane <[email protected]>
Tue, 1 Sep 2020 17:14:44 +0000 (13:14 -0400)
committerTom Lane <[email protected]>
Tue, 1 Sep 2020 17:14:44 +0000 (13:14 -0400)
commit8d486cfbf249cf48bf769e4cfc967692c24faefd
treee183b77de8ed9710f9f989d7e62caf05fa114be7
parent2dbe3ea7a85473ff4b32eebf1508e1c604d8b7da
Teach libpq to handle arbitrary-length lines in .pgpass files.

Historically there's been a hard-wired assumption here that no line of
a .pgpass file could be as long as NAMEDATALEN*5 bytes.  That's a bit
shaky to start off with, because (a) there's no reason to suppose that
host names fit in NAMEDATALEN, and (b) this figure fails to allow for
backslash escape characters.  However, it fails completely if someone
wants to use a very long password, and we're now hearing reports of
people wanting to use "security tokens" that can run up to several
hundred bytes.  Another angle is that the file is specified to allow
comment lines, but there's no reason to assume that long comment lines
aren't possible.

Rather than guessing at what might be a more suitable limit, let's
replace the fixed-size buffer with an expansible PQExpBuffer.  That
adds one malloc/free cycle to the typical use-case, but that's surely
pretty cheap relative to the I/O this code has to do.

Also, add TAP test cases to exercise this code, because there was no
test coverage before.

This reverts most of commit 2eb3bc588, as there's no longer a need for
a warning message about overlength .pgpass lines.  (I kept the explicit
check for comment lines, though.)

In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not
much point in explicit_bzero'ing the line buffer if we only do so in two
of the three exit paths.

Back-patch to all supported branches, except that the test case only
goes back to v10 where src/test/authentication/ was added.

Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
src/interfaces/libpq/fe-connect.c