> On Mar 28, 2017, at 9:47 AM, Dave Page <dp...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
