Re: primary_conninfo missing from pg_stat_wal_receiver

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> > On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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?
>
> > Yes it could, as a connection string, but we make the information of
> > this view only visible to superusers. For the others, that's just
> > NULL.
>
> Well, that's okay for now, but I'm curious to hear Stephen Frost's
> opinion on this. He's been on the warpath to decrease our dependence
> on superuser-ness for protection purposes. Seems to me that having
> one column in this view that is a lot more security-sensitive than
> the others is likely to be an issue someday.

Ugh. I would certainly rather not have yet another special, hard-coded,
bit of logic that magically makes things available to a superuser when
it's not available to regular users.

What that results in is the need to have a new default role to control
access to that column for the non-superuser case.

As for the password showing up, sorry, but we need a solution for *that*
regardless of the rest- the password shouldn't be exposed to anyone, nor
should it be sent and kept in the backend's memory for longer than
necessary. I'm not suggesting we've got that figured out already, but
that's where we should be trying to go.

Apologies, I've not followed this thread entirely, so these comments are
based only on what's quoted above. I'll try to read the complete thread
tomorrow.

Thanks!

Stephen