On Mon, Aug 31, 2015 at 9:04 PM, Magnus Hagander <magnus@hagander.net> wrote: > > > On Sun, Aug 30, 2015 at 5:35 AM, Michael Paquier <michael.paquier@gmail.com> > wrote: >> >> >> >> On Sun, Aug 30, 2015 at 5:27 AM, Bruce Momjian wrote: >>> >>> I know I am coming in late here, but I know Heroku uses random user >>> names to allow a cluster to have per-user databases without showing >>> external user name details: >>> [...] >>> I can see them having problems with a user being able to see the SSL >>> remote user names of all connected users. >> >> >> Yep, and I can imagine that this is the case of any company managing cloud >> nodes with Postgres embedded, and at least to me that's a real concern. > > > > How is it a concern that a CN field with a random username in it is > visible, when showing the actual random username isn't? That's not very > consistent...
How can you be sure as well that all such deployments would use random CN fields and/or random usernames? We have no guarantee of that as well.
Sure.
But how can we be sure that all such deployments use random usernames? We can't, and we still show the username to people. (And I'm willing to be it's a *lot* more common that hosters have sensitive information in the username - like customer name - than that they have it in a client certificate. Simply because most of them don't use client certificates).
If we're worried about that, we should also blank out username and maybe database name from pg_stat_activity. And probably application_name as well. If we're not doing that, then we're not being at all consistent. If we are talking about doing that (before we have figured out the granular permissions part), then we should do the pg_stat_ssl CN at the same time, I definitely agree with that.
I can agree that there are some other fields that potentially leak some information, like which crypto is in use. But I'm with Andres in the summary - I think the way to fix that is once we have figured out actual more granular permissions, and not by locking it down now.
