Re: [PATCH] pgpassfile connection option

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Julian Markwort <julian(dot)markwort(at)uni-muenster(dot)de>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] pgpassfile connection option
Date: 2016-10-16 10:09:27
Message-ID: alpine.DEB.2.20.1610161103250.7688@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

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...


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-10-16 13:01:44 Re: COPY as a set returning function
Previous Message Julien Rouhaud 2016-10-16 09:52:32 Re: pg_stat_statements and non default search_path