Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup
От | Tom Lane |
---|---|
Тема | Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup |
Дата | |
Msg-id | 8643.1007142938@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup
Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup |
Список | 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 по дате отправления: