Re: pg_upgrade using appname to lock out otherusers - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade using appname to lock out otherusers
Date
Msg-id 201106181334.p5IDYwY05750@momjian.us
Whole thread Raw
In response to Re: pg_upgrade using appname to lock out otherusers  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade using appname to lock out other users
List pgsql-hackers
Bruce Momjian wrote:
> I meant the PGPASSWORD environment variable:
>
>       <indexterm>
>        <primary><envar>PGPASSWORD</envar></primary>
>       </indexterm>
>       <envar>PGPASSWORD</envar> behaves the same as the <xref
>       linkend="libpq-connect-password"> connection parameter.
>       Use of this environment variable
>       is not recommended for security reasons, as some operating systems
>       allow non-root users to see process environment variables via
>       <application>ps</>; instead consider using the
>       <filename>~/.pgpass</> file (see <xref linkend="libpq-pgpass">).
>
> The only other way to do this is to pass it on the command line, but
> some options don't allow that (pg_ctl), and PGPASSFILE is going to
> require me to create a dummy .pgpass password file in a valid format and
> use that.

One interesting idea would be to write the server password in the
PGPASSFILE format, and allow the server and libpq to read the same file
by pointing PGPASSFILE at that file.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Don't use "cp -i" in the example WAL archive_command.
Next
From: Noah Misch
Date:
Subject: Re: crash-safe visibility map, take five