Re: PGPASSWORD

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PGPASSWORD
Дата
Msg-id 9002.1109367533@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PGPASSWORD  (postgresbugs <postgresbugs@grifent.com>)
Ответы Re: PGPASSWORD  (postgresbugs <postgresbugs@grifent.com>)
Список pgsql-bugs
postgresbugs <postgresbugs@grifent.com> writes:
> Unless the utilities like psql and pg_dump are changed to accept a
> password as a command line option, I don't think PGPASSWORD should go
> away. It is too useful for those that know how to properly use and
> destroy environmental variables.

... which evidently does not include you.  The point here is that if
PGPASSWORD is passed down to psql as an environmental variable, it is
visible as part of psql's environment for the entire run of psql.
Whatever the calling script does later doesn't remove that window of
vulnerability.

There is no intention of removing PGPASSWORD, because it is safe and
useful *on platforms that do not expose other processes' environment
variables*.  But it is deprecated and will remain so, because there
are too many platforms where this is not true.

> Again, the advantage is I can let users with no database login have
> controlled access to database data and utilities without them actually
> having a user name and password to the database. Without the ability to
> use PGPASSWORD, I have to expose the password in a .pgpass file for
> every user I want to allow access. I think that is far more insecure.

If .pgpass is properly protected, I do not see why you think it is
insecure.  It's certainly a lot safer than environment variables.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Oliver Jowett
Дата:
Сообщение: Re: PGPASSWORD
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PGPASSWORD