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


From: postgresbugs <postgresbugs(at)grifent(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Date: 2005-02-25 21:22:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Oliver Jowett wrote:

> Tom Lane wrote:
>> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>>> Assuming that you can't tweak .pgpass (for example, you're just 
>>> propagating a password you interactively got from the user), what's 
>>> the recommended way to provide the password?
>> In the connection string given to PQconnectdb (or equivalent).
> If you're a shell script calling psql / pg_dump / etc, how do you do 
> this?
> -O

Exactly. Also, when a script is executed from a binary and the password 
is passed in as a parameter and PGPASSWORD is set inside the script, it 
is local to the script.

I understand that on some operating systems environmental variables may 
be seen by anyone on the system. In every Linux, UNIX, and even Win 2k 
with batch files, the variable can be local and even if exported can be 
unset by the script before it exits.

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. The documentation points out that the 
use of PGPASSWORD can be dangerous on some systems. I think it is up to 
the administrators of those systems to make that choice to use or not 
use rather than have a very useful mechanism removed with no viable 

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.

John Griffiths

In response to


pgsql-bugs by date

Next:From: Oliver JowettDate: 2005-02-25 21:33:27
Previous:From: Tom LaneDate: 2005-02-25 21:09:13

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