| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Leonhard <michael(at)leonhardllc(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Add PGURI env var for passing connection string to psql in Docker |
| Date: | 2020-02-20 20:20:55 |
| Message-ID: | 21551.1582230055@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Leonhard <michael(at)leonhardllc(dot)com> writes:
> I need to pass a connection string to psql inside Docker [2]. I can
> pass it as a process argument, but this exposes the password to other
> processes on my machine:
> $ docker run --rm -i -t postgres:11 psql "$(cat db_uri)"
Yeah, if you include the password in the URI :-(
> How about adding PGURI to the list of supported environment variables [3]?
That will not fix your security problem, because on a lot of OSes,
environment variables are *also* visible to other processes.
There are other practical problems with such a proposal, mainly that
it's not clear how such a variable ought to interact with existing
connection-control variables (eg, if you set both PGURI and PGHOST,
which wins?)
The only safe way to deal with a password is to have some other
out-of-band way to pass it. That's one reason for the popularity
of ~/.pgpass files. Alternatively, look into non-password
authentication methods.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2020-02-20 20:50:29 | Re: pgsql: Add kqueue(2) support to the WaitEventSet API. |
| Previous Message | Tom Lane | 2020-02-20 19:56:57 | Re: pgsql: Add kqueue(2) support to the WaitEventSet API. |