Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup
Date
Msg-id 8643.1007142938@sss.pgh.pa.us
Whole thread Raw
In response to Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup
Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We can hide it but it will be visible for a short period, and many
> operating systems either don't allow us to modify the ps args or have
> ways of circumventing custom ps display, i.e. it doesn't show updated ps
> display if the process is swapped out because ps can't get to the
> user-space definitions of the custom args.

Yes, passwords in command-line arguments are *way* too dangerous.

I had always thought that environment vars were secure, though, and was
surprised to learn that there are Unix variants wherein they're not.

I still like the idea of arguments and/or env vars that give the name
of a file in which to look for the password, however.  Perhaps the file
contents could be along the lines of
username    host    password

and libpq would look for a line matching the PGUSER and PGHOST values it
already has.  (compare the usage of .netrc, .cvspass, etc).  Maybe there
could even be a default assumption that we look in "$HOME/.pgpass",
without having to be told?  Or is that too Unix-centric?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: initdb + locale problem
Next
From: Bruce Momjian
Date:
Subject: Re: History question