Skip site navigation (1) Skip section navigation (2)

Re: PGPASSWORD

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: postgresbugs <postgresbugs(at)grifent(dot)com>
Cc: Oliver Jowett <oliver(at)opencloud(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: PGPASSWORD
Date: 2005-02-25 21:38:53
Message-ID: 9002.1109367533@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
postgresbugs <postgresbugs(at)grifent(dot)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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2005-02-25 21:49:48
Subject: Re: PGPASSWORD
Previous:From: Oliver JowettDate: 2005-02-25 21:33:27
Subject: Re: PGPASSWORD

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group