Thread: 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, Pennsylvania19026
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 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 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, Pennsylvania19026
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, Pennsylvania19026
> 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? 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, Pennsylvania19026