05.10.2016, 20:06, Robert Haas kirjoitti:
> You could do something like that, I guess, but I think it might be a
> good idea to wait and see if anyone else has opinions on (1) the
> desirability of the basic feature, (2) the severity of the security
> hazard it creates, and (3) your proposed remediation method.
I don't think it's appropriate to compare the proposed pgpassfile option
to sslkey: the key is never transmitted over the network anywhere.
> So far I don't see anybody actually endorsing your proposal here,
> which might mean that any patch you produce will be rejected on the
> grounds that nobody has a clear use case for this feature.
>
> Hey, everybody: chime in here...
The original patch didn't come with a description of the problem it was
aiming to solve, but I've wanted something perhaps a bit similar in the
past.
The pghoard backup & restore suite we maintain needs to be able to spawn
pg_basebackup and pg_receivexlog processes and in order to avoid passing
passwords in command-line arguments visible to everyone who can get a
process listing we currently have pghoard edit pgpass files.
Having to edit pgpass files at all is annoying and there isn't really a
good way to do it: we can edit the one at $HOME and hope it doesn't
clash with the expectations of the user running the software, write it
to a custom file somewhere else - copying the password to a location the
user might not expect - or create a new temporary file on every invocation.
I came across some bad advice about passing passwords to libpq today:
there was a recommendation for setting a $PASSWORD environment variable
and including that in the connection string, using shell to expand it.
It got me thinking that maybe such a feature could be implemented in
libpq: have it expand unquoted $variables; for example:
$ PASSWORD=xyz psql 'password=$PASSWORD dbname=foo'
This does have the hazard of making it very easy to accidentally use
double quotes instead of single quotes and have the shell expand the
variable making it visible in process listing though.
/ Oskari
