> 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
