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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: FW: [ppa-dev] Severe bug in debian - phppgadmin opensup  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: initdb + locale problem
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: History question