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