From: Bruce Momjian <bruce@momjian.us>
Message-Id: <200701280135.l0S1ZPT01054@momjian.us>
Subject: Re: Password issue revisited
In-Reply-To: <BAY114-DAV1235968436BFC871B4AEB7A3A00@phx.gbl>
To: Michael Schmidt <michaelmschmidt@msn.com>
Date: Sat, 27 Jan 2007 20:35:25 -0500 (EST)
CC: PostgreSQL General <pgsql-general@postgresql.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

Michael Schmidt wrote:
> Fellow PostgreSQL fans, Last year there was a pretty lengthy discussion
> (Tom Lane offered a lot of insights) on this list about deprecating
> the PGPASSWORD environmental variable.  I understand the security issues
> here very well.  However, up through version 8.1, it has been easy to
> use pg_dump and pg_restore from other applications (PHP, Java, etc.)
> by capturing the Password prompt on stderr and sending the password on
> stdin.  No more.  Now, this interaction is done on low-level I/O data
> streams.  Also, it appears from the documentation that the PGPASSFILE
> environmental variable has been deprecated for pg_dump and pg_restore.
> It appears the only way these utilities can run from a script or other
> application is to ensure that the user specified in the command-line
> has a .pgpass file.
> 
> I would like to ask that we return to outputting the Password prompt
> on stderr and accepting password input on stdin.  Here are the reasons.

Unlikely.

> 1.  I don't see that this would pose a major security risk.  In fact,
> in applications where the user enters the password for each session,
> the password need never be saved to disk, which seems a definite
> security advantage.  Some folks have noted that .pgpass is a plain text
> file, hence it could be vulnerable.

This doesn't work if the command actually is taking data from stdin.

> 2.  PostgreSQL has a tradition of respecting generally accepted
> standards.  The use of high-level input/output is a standard for many
> programming languages.

It is _not_ typical to read a password from stdin.  I am sure you can
find some tools that do this, but most do not.

> 3.  PostgreSQL has a tradition of cross-platform compatibility.  Use
> of high-level input/output allows cross-platform applications (e.g.,
> Java) to interact with PostgreSQL in a straightforward and standardized
> fashion.

> 4.  Low level input/output is considerably more difficult and less
> reliable for other applications to access and work with.

The change is to read from /dev/tty.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +