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
>>> settings.
>>>
>>
>> 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
itself protected.
> 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.
cheers
andrew
