Re: Information of pg_stat_ssl visible to all users

On Wed, Jul 8, 2015 at 3:29 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Josh Berkus (josh(at)agliodbs(dot)com) wrote:
>> On 07/07/2015 09:06 AM, Magnus Hagander wrote:
>> >
>> > To make it accessible to monitoring systems that don't run as superuser
>> > (which should be most monitoring systems, but we have other cases making
>> > that hard as has already been mentioned upthread).
>> >
>> > I'm having a hard time trying to figure out a consensus in this thread.
>> > I think there are slightly more arguments for limiting the access though.
>> >
>> > The question then is, if we want to hide everything, do we care about
>> > doing the "NULL dance", or should we just throw an error for
>> > non-superusers trying to access it?
>>
>> I'm going to vote against blocking the entire view for non-superusers.
>> One of the things people will want to monitor is "are all connection
>> from subnet X using SSL?" which is most easily answered by joining
>> pg_stat_activity and pg_stat_ssl.
>>
>> If we force users to use superuser privs to find this out, then we're
>> encouraging them to run monitoring as superuser, which is something we
>> want to get *away* from.
>
> I agree with all of this, but I'm worried that if we make it available
> now then we may not be able to hide it later, even once we have the
> monitoring role defined, because of backwards compatibility concerns.
>
> If we aren't worried about that, then perhaps we can leave it less
> strict for 9.5 and then make it stricter for 9.6.

Agreed. It is better to make things strict first and relax afterwards
from the user prospective, so I would vote for something in this
direction. We could relax it with this monitoring ACL afterwards in
9.6, still what I think we are missing here are reactions from the
field, and I suspect that taking the most careful approach (hiding a
maximum of fields to non-authorized users) will pay better in the long
term. I am also suspecting that if we let it as-is cloud deployments
of Postgres (Heroku for example) are going to patch this view with ACL
checks.
--
Michael