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'd be OK with concealing some columns:
postgres=# select * from pg_stat_ssl;pid | ssl | version | cipher | bits | compression
| clientdn
-----+-----+---------+-----------------------------+------+-------------+---------- 37 | t | TLSv1.2 |
ECDHE-RSA-AES256-GCM-SHA384| 256 | f |
I can see NULLifying cipher and DN columns. The other columns, it's
hard to imagine what use an attacker could put them to that they
wouldn't be able to find out the same information easily using other routes.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com