Re: primary_conninfo missing from pg_stat_wal_receiver

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-28 21:42:35
Message-ID: 20160628214235.GA54004@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier wrote:

> I have been thinking more about that, and came up with the following
> idea... We do not want to link libpq directly to the server, so let's
> add a new routine to libpqwalreceiver that builds an obfuscated
> connection string and let's have walreceiver.c save it in shared
> memory. Then pg_stat_wal_receiver just makes use of this string. This
> results in a rather light patch, proposed as attached. Connection URIs
> get as well translated as connection strings via PQconninfo(), then
> the new interface routine of libpqwalreceiver looks at dispchar to
> determine if it should dump a field or not and obfuscates it with more
> or less '****'.

Seems a reasonable idea to me, but some details seem a bit strange:

* Why obfuscate debug options instead of skipping them?
* why not use PQExpBuffer?
* Why have the return param be an output argument instead of a plain
return value? i.e. static char *libpqrcv_get_conninfo(void).

On the security aspect of "conninfo" itself, which persists in shared
memory: do we absolutely need to keep that data? In my reading of the
code, it's only used once to establish the initial connection to the
walsender, and then never afterwards. We could remove the disclosure by
the simple expedient of overwriting that struct member with the
obfuscated one, right after establishing that connection. Then we don't
need an additional struct member safe_conninfo. Is there a reason why
this wouldn't work?

I have already edited the patch following some of these ideas. Will
post a new version later.

--
Álvaro Herrera 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 Stefan Keller 2016-06-28 23:51:38 Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)
Previous Message Oleg Bartunov 2016-06-28 21:27:46 Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?