Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup
Of course, given that most OS's don't have the 'ps' environment
problem,
maybe we have to keep PGPASSWORD around. It is up to the group. Do
people want me to change my wording of the option in the SGML sources?<envar>PGPASSWORD</envar>
sets the password used if the backend demands password
authentication. This is not recommended because the password can
be read by others using a <command>ps</command> environment flag
on some platforms.
I think the wording is good. I would keep supporting the envar.
What exactly speaks against a commandline switch, that gets hidden
with the postmaster argv trick, and a similar notice as for PGPASSWORD.
For me, this would be the most convenient form of supplying a password
(if I used db side passwords :-).
Andreas
Of course, given that most OS's don't have the 'ps' environment
problem,
maybe we have to keep PGPASSWORD around. It is up to the group. Do
people want me to change my wording of the option in the SGML sources?<envar>PGPASSWORD</envar>
sets the password used if the backend demands password
authentication. This is not recommended because the password can
be read by others using a <command>ps</command> environment flag
on some platforms.I think the wording is good. I would keep supporting the envar.
What exactly speaks against a commandline switch, that gets hidden
with the postmaster argv trick, and a similar notice as for PGPASSWORD.
For me, this would be the most convenient form of supplying a password
(if I used db side passwords :-).
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.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
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
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 ofusername 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
Yes, this is more powerful than the environment variable anyway. We
only have to decide how to specify missing fields. Asterisk?
could even be a default assumption that we look in "$HOME/.pgpass",
without having to be told? Or is that too Unix-centric?
You mean like we do for .psqlrc. Good idea.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
username host password
Yes, this is more powerful than the environment variable anyway. We
only have to decide how to specify missing fields. Asterisk?
Uh, *what* missing fields? It's not clear to me that there's any value
in a wild-card entry in this thing.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
username host password
Yes, this is more powerful than the environment variable anyway. We
only have to decide how to specify missing fields. Asterisk?Uh, *what* missing fields? It's not clear to me that there's any value
in a wild-card entry in this thing.
I think so. What if you password is the same for all hosts? Wouldn't
you want:
username * password
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I think so. What if you password is the same for all hosts?
We should encourage that? I don't think so ...
regards, tom lane
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 ofusername 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?
TODO updated:
* Add PGPASSWORDFILE environment variable or ~/.pgpass to store
user/host/password combinations
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026