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


From: postgresbugs <postgresbugs(at)grifent(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Date: 2005-02-26 03:51:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs

Oliver Jowett wrote:

> postgresbugs wrote:
>> Tom Lane wrote:
>>> 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.
> [...]
>> And, yes I do understand that for the brief period the environmental 
>> variable could possibly be visible on some platforms, but even 
>> Windows has the local directive which makes the variable far more 
>> secure. 
> The window is much longer than that. As Tom said, for PGPASSWORD to 
> work it has to be present in the environment of the psql process -- 
> that's how psql gets the password! That environment may be visible to 
> other users of the system, depending on the OS. psql could remove the 
> password after use, I suppose, but that just narrows the window.
> IMO *any* window of vulnerability is unacceptable -- it opens up any 
> periodic or triggerable process to an attacker who tries to get the 
> timing just right (not impossible to do if you can also slow down the 
> system you are attacking to widen the window..)
> PGPASSWORD is just a bad idea as a general mechanism. We need some 
> other way.
> -O

I agree that there can be a window of vulnerability. What I am saying is 
that window has been and is currently in the Postgres system since 
PGPASSWORD does still work. All I am saying is that the choice to risk 
that period of vulnerability should be up to the administrator of the 
system. The functionality provided by PGPASSWORD should not be removed 
unless there is a functionality other than .pgpass, which is fine for 
some uses and not for others, that will provide similar functionality. 
That could be psql and pg_dump and the like accepting a password on the 
command line as I stated earlier. If the PGPASSWORD functionality is 
removed at some point (implied by being termed deprecated) without a 
viable alternative other than .pgpass, then I will be stuck in time at 
the last version that still provides that functionality. Not that anyone 
should care about that; I'm just stating a fact.

I really appreciate all the effort that is put into Postgres by all the 
developers. My sole purpose for bringing this subject up was to make the 
developers aware that the functionality is used and that .pgpass does 
not solve all the issues of password requirement.

John Griffiths

In response to


pgsql-bugs by date

Next:From: Oliver JowettDate: 2005-02-26 11:26:28
Previous:From: John R PierceDate: 2005-02-25 23:34:24

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