| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> | 
|---|---|
| To: | Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> | 
| Cc: | Thomas Bley <thbley(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: password is no required, authentication is overridden | 
| Date: | 2006-07-19 12:55:18 | 
| Message-ID: | 44BE2BB6.9010002@dunslane.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | MotherMGA | 2006-07-19 13:04:24 | Re: Possible Typecasting Bug with coalesce() | 
| Previous Message | Andreas Pflug | 2006-07-19 12:35:42 | Re: password is no required, authentication is overridden |