Re: primary_conninfo missing from pg_stat_wal_receiver

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

In response to

Responses

Browse pgsql-hackers by date

  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