aboutsummaryrefslogtreecommitdiff
path: root/src/bin/psql/help.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2010-03-06 00:45:49 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2010-03-06 00:45:49 +0000
commitb8b34b7b44ee7d932b2a1317232ff15fb72cf1a7 (patch)
treec5aa3d4dc1a314df3a0d6491f3bdf36de5453f1c /src/bin/psql/help.c
parent8eb81949a555075efefec70af37acf1f739dc420 (diff)
downloadpostgresql-b8b34b7b44ee7d932b2a1317232ff15fb72cf1a7.tar.gz
postgresql-b8b34b7b44ee7d932b2a1317232ff15fb72cf1a7.zip
When reading pg_hba.conf and similar files, do not treat @file as an inclusion
unless (1) the @ isn't quoted and (2) the filename isn't empty. This guards against unexpectedly treating usernames or other strings in "flat files" as inclusion requests, as seen in a recent trouble report from Ed L. The empty-filename case would be guaranteed to misbehave anyway, because our subsequent path-munging behavior results in trying to read the directory containing the current input file. I think this might finally explain the report at http://archives.postgresql.org/pgsql-bugs/2004-05/msg00132.php of a crash after printing "authentication file token too long, skipping", since I was able to duplicate that message (though not a crash) on a platform where stdio doesn't refuse to read directories. We never got far in investigating that problem, but now I'm suspicious that the trigger condition was an @ in the flat password file. Back-patch to all active branches since the problem can be demonstrated in all branches except HEAD. The test case, creating a user named "@", doesn't cause a problem in HEAD since we got rid of the flat password file. Nonetheless it seems like a good idea to not consider quoted @ as a file inclusion spec, so I changed HEAD too.
Diffstat (limited to 'src/bin/psql/help.c')
0 files changed, 0 insertions, 0 deletions