From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, vik(at)2ndquadrant(dot)fr, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Masao Fujii <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: primary_conninfo missing from pg_stat_wal_receiver |
Date: | 2016-06-21 03:00:07 |
Message-ID: | 562f6c7f-6a47-0a8a-e189-2de9ea896849@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/20/16 10:29 PM, Tom Lane wrote:
> What I would want to know is whether this specific change is actually a
> good idea. In particular, I'm concerned about the possible security
> implications of exposing primary_conninfo --- might it not contain a
> password, for example?
That would have been my objection. This was also mentioned in the
context of moving recovery.conf settings to postgresql.conf, because
then the password would become visible in SHOW commands and the like.
We would need a way to put the password in a separate place, like a
primary_conn_password setting. Yes, you can already use .pgpass for
that, but since pg_basebackup -R will happily copy a password out of
.pgpass into recovery.conf, this makes accidentally leaking passwords
way too easy.
Alternatively or additionally, implement a way to strip passwords out of
conninfo information. libpq already has information about which
connection items are sensitive.
Needs more thought, in any case.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-21 03:01:50 | Re: Parallel query and temp_file_limit |
Previous Message | Tom Lane | 2016-06-21 02:51:48 | Re: primary_conninfo missing from pg_stat_wal_receiver |