My 0.02€:
Patch applies cleanly, make check ok... however AFAICS it only means that
it compiles but it is not tested in anyway... This is is annoying. Well
I'm not sure whether other options are tested either, but they should.
ISTM that this feature is already available through the PGPASSFILE
environment variable, so this is really just about providing the same
feature through a connection string option, if I'm not mistaken. I'm fine
with that.
The documentation needs to be updated.
I'm not much concerned about security issues as discussed on the thread.
If an attacker can control the file, then what... they can provide a
password in my place in a file of their own? If they have the pass then it
works, if they do not then the connection will fail... They cannot change
the database I'm connecting to from the pass file, say to provide other
credentials to an application. So I do not see this as worst that the
current status.
I tested the feature through python/psychopg2 by setting LD_LIBRARY_PATH
to the dev version. I got a strange behavior wrt to errors. With "./foo"
containing the right password it is fine.
import psycopg2 as pg
c = pg.connect("host=localhost dbname=test user=test pgpassfile=./foo")
# ok
c.close()
Now if "./foo" contains a bad password:
import psycopg2 as pg
c = pg.connect("host=localhost dbname=test user=test pgpassfile=./foo")
# error:
OperationalError: FATAL: password authentication failed for user "test"
password retrieved from file "$HOME/.pgpass"
The reported password file is wrong. It is even more funny if ~/.pgpass
contains the right password: the pgpassfile option *is* taken into
account, ./foo is read and it fails, but the error message is not
updated and points to the wrong file. The error message stuff should be
updated to look for the pgpassfile connection string option...
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
