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
|
Список | 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 по дате отправления: