|
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.
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.
2. PostgreSQL has a tradition of respecting generally accepted
standards. The use of high-level input/output is a standard for many
programming languages.
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.
Thanks for considering this matter.
Michael Schmidt
|
