Re: PGPASSWORD - Mailing list pgsql-bugs

From Tom Lane
Subject Re: PGPASSWORD
Date
Msg-id 9002.1109367533@sss.pgh.pa.us
Whole thread Raw
In response to Re: PGPASSWORD  (postgresbugs <postgresbugs@grifent.com>)
Responses Re: PGPASSWORD  (postgresbugs <postgresbugs@grifent.com>)
List 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 by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: PGPASSWORD
Next
From: Tom Lane
Date:
Subject: Re: PGPASSWORD