Re: PGPASSWORD and client tools

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: PGPASSWORD and client tools
Дата
Msg-id 41240A49.7010607@dunslane.net
обсуждение исходный текст
Ответ на Re: PGPASSWORD and client tools  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PGPASSWORD and client tools  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

Tom Lane wrote:

>Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>  
>
>>>After some tests, I found that using the PGPASSWORD environment variable 
>>>will do the job. I'm a bit irritated that it's marked "deprecated" in 
>>>the docs, the .pgpass solution isn't a good one for tool managed passwords.
>>>      
>>>
>
>  
>
>>I didn't notice it was deprecated either - it's the only way that 
>>phpPgAdmin can integrate with pg_dump...
>>    
>>
>
>It's deprecated because it's insecure, on platforms where other users can
>see the environment variables passed to pg_dump (which apparently is
>quite a few variants of Unix).  You wouldn't pass the password on the
>command line either ...
>
>Painful as .pgpass may be for an admin tool, I do not know of any other
>method I'd recommend on a multiuser machine.
>
>
>  
>

How about an environment variable that points to a .pgpass type file. Or 
we could even play games with PGPASSWORD - if it names an existing file 
that satisfies the .pgpass criteria then it will be taken as the 
location of the .pgpass file instead of $HOME/.pgpass - otherwise its 
value will be considered to be the password itself. The Chris could have 
phppgadmin write the password file, set the environment var and call 
pg_dump happily (and remove the file afterwards).

cheers

andrew


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: More fun with dropped columns
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PGPASSWORD and client tools