Re: Monitoring roles patch

> On Mar 28, 2017, at 9:47 AM, Dave Page <dpage@pgadmin.org> wrote:
> 
>> Does
>> pg_read_all_stats still have access to stats for mysecuretable?
> 
> Yes, because the ACL on the table controls reading/writing the data in
> the table. It doesn't have any bearing on any kind of table metadata.
> A user who has no privileges on a table can already look at (for
> example) pg_stat_all_tables and see the sort of info you're talking
> about. This patch would just allow members of a specific role get the
> on-disk size as well, *if* you choose to use it.

I don't entirely agree here.  Security conscious database users may well
restrict access to that view.  I added a check to the regression tests to
verify that it works:

+ SET ROLE regress_locktable_user;
+ SELECT COUNT(*) FROM pg_stat_all_tables;
+  count 
+ -------
+    290
+ (1 row)
+ 
+ RESET ROLE;
+ REVOKE ALL PRIVILEGES ON pg_stat_all_tables FROM PUBLIC;
+ SET ROLE regress_locktable_user;
+ SELECT COUNT(*) FROM pg_stat_all_tables;
+ ERROR:  permission denied for relation pg_stat_all_tables
+ RESET ROLE;
+ SELECT COUNT(*) FROM pg_stat_all_tables;
+  count 
+ -------
+    292
+ (1 row)
+ 

The inability to revoke access to this sort of information being proposed
makes me a bit uneasy.  Mostly, I think, I'm bothered because there may
be people who have revoked privileges on a lot of things, thereby restricting
access to superuser, who won't necessarily notice this new feature in
postgres 10.  That could be a source of security holes that we get blamed
for.

Please note that I'm not specifically opposed to this work, and see a lot
of merit here.  I'm just thinking about unintended consequences.

mark