Hiroshi Saito wrote:
From: "Andrew Dunstan"
Thomas Bley wrote:
+ The .pgpass file will be automatically created if you're using
pgAdmin III with "store password" being enabled in the connection
It strikes me that this is actually a bad thing for pgadmin3 to be
doing. It should use its own file, not the deafult location, at least
if the libpq version is >= 8.1. We provided the PGPASSFILE
environment setting just so programs like this could use alternative
locations for the pgpass file. Otherwise, it seems to me we are
violating the POLS, as in the case of this user who not unnaturally
thought he had found a major security hole.
Ummm, The function which pgAdmin offers is the optimal in present. I
do not think that PGPASSFILE avoids the danger clearly. Probably, It
is easy for the user who is malicious in the change to find it.
I don't understand what you are saying here. The problem is that it is
not clear (at least to the original user, and maybe to others) that when
pgadmin3 saves a password it saves it where it will be found by all
libpq clients, not just by pgadmin3. How is that optimal? If pgadmin3
were to save it in a non-standard location and then set PGPASSFILE to
point to that location that would solve the problem. Or maybe it should
offer a choice. Either way, how would a malicious user affect that?
PGPASSFILE only contains a location, not the contents of the file, so
exposing it is not any great security issue, as long as the location is
I consider it to be a problem that the password is finally PlainText.
Then, I made the proposal before. However,
It was indicated that deliberation is required again..... I want to
consider a good method again. Is there any proposal with good someone?
Use of plaintext in pgpass files is a different problem.
If you really want high security you need to get out of the game of
shared passwords altogether, and use client certificates, IMNSHO.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?