Обсуждение: BUG #16279: Permissions doc incorrect for pg_buffercache
The following bug has been logged on the website: Bug reference: 16279 Logged by: Philip Semanchuk Email address: philip@americanefficient.com PostgreSQL version: 11.6 Operating system: macOS, also AWS Aurora Description: The doc for pg_buffercache says, "By default use is restricted to superusers and members of the pg_read_all_stats role. Access may be granted to others using GRANT." (https://www.postgresql.org/docs/11/pgbuffercache.html) In my experience, users need to be members of pg_monitor, not pg_read_all_stats. Here's a demo on Postgres 11.6 installed on my Mac. (Behavior on AWS Aurora Postgres is the same.) 'a_user' is a user with no special privileges. This first block of SQL shows that a_user can't read pg_buffercache, as expected. a_user $ SELECT r.rolname, r.rolsuper, r.rolinherit, r.rolcreaterole, r.rolcanlogin, r.rolvaliduntil, ARRAY(SELECT b.rolname FROM pg_catalog.pg_auth_members m JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid) WHERE m.member = r.oid) as memberof FROM pg_catalog.pg_roles r WHERE rolname = current_user ; rolname | rolsuper | rolinherit | rolcreaterole | rolcanlogin | rolvaliduntil | memberof ---------+----------+------------+---------------+-------------+---------------+---------- a_user | f | t | f | t | | {} (1 row) a_user $ a_user $ select * from pg_buffercache limit 1; ERROR: permission denied for view pg_buffercache In a different session where I'm logged in as superuser, I GRANTed a_user membership to pg_read_all_stats, but a_user still can't read from pg_buffercache. a_user $ SELECT r.rolname, r.rolsuper, r.rolinherit, r.rolcreaterole, r.rolcanlogin, r.rolvaliduntil, ARRAY(SELECT b.rolname FROM pg_catalog.pg_auth_members m JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid) WHERE m.member = r.oid) as memberof FROM pg_catalog.pg_roles r WHERE rolname = current_user ; rolname | rolsuper | rolinherit | rolcreaterole | rolcanlogin | rolvaliduntil | memberof ---------+----------+------------+---------------+-------------+---------------+--------------------- a_user | f | t | f | t | | {pg_read_all_stats} (1 row) a_user $ select * from pg_buffercache limit 1; ERROR: permission denied for view pg_buffercache In my superuser session, I REVOKEd a_user's membership in pg_read_all_stats and GRANTed membership in pg_monitor, and that enabled access to pg_buffercache. a_user $ SELECT r.rolname, r.rolsuper, r.rolinherit, r.rolcreaterole, r.rolcanlogin, r.rolvaliduntil, ARRAY(SELECT b.rolname FROM pg_catalog.pg_auth_members m JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid) WHERE m.member = r.oid) as memberof FROM pg_catalog.pg_roles r WHERE rolname = current_user ; rolname | rolsuper | rolinherit | rolcreaterole | rolcanlogin | rolvaliduntil | memberof ---------+----------+------------+---------------+-------------+---------------+-------------- a_user | f | t | f | t | | {pg_monitor} (1 row) a_user $ a_user $ select * from pg_buffercache limit 1; bufferid | relfilenode | reltablespace | reldatabase | relforknumber | relblocknumber | isdirty | usagecount | pinning_backends ----------+-------------+---------------+-------------+---------------+----------------+---------+------------+------------------ 1 | 1262 | 1664 | 0 | 0 | 0 | f | 5 | 0 (1 row) a_user $
Hello You are right, in contrib/pg_buffercache/pg_buffercache--1.2--1.3.sql we have GRANT EXECUTE ON FUNCTION pg_buffercache_pages() TO pg_monitor; GRANT SELECT ON pg_buffercache TO pg_monitor; Not pg_read_all_stats. I'm not sure: we need change the extension or fix the documentation? I think pg_read_all_stats wouldbe more appropriate, but we need bump the extension version. regards, Sergei
> On Feb 26, 2020, at 12:11 PM, Sergei Kornilov <sk@zsrv.org> wrote: > > Hello > > You are right, in contrib/pg_buffercache/pg_buffercache--1.2--1.3.sql we have > > GRANT EXECUTE ON FUNCTION pg_buffercache_pages() TO pg_monitor; > GRANT SELECT ON pg_buffercache TO pg_monitor; > > Not pg_read_all_stats. I'm not sure: we need change the extension or fix the documentation? I think pg_read_all_stats wouldbe more appropriate, but we need bump the extension version. Thanks for exploring and confirming! I agree that pg_read_all_stats would be more appropriate. Cheers Philip
Philip Semanchuk <philip@americanefficient.com> writes: > On Feb 26, 2020, at 12:11 PM, Sergei Kornilov <sk@zsrv.org> wrote: >> You are right, in contrib/pg_buffercache/pg_buffercache--1.2--1.3.sql we have >> GRANT EXECUTE ON FUNCTION pg_buffercache_pages() TO pg_monitor; >> GRANT SELECT ON pg_buffercache TO pg_monitor; >> Not pg_read_all_stats. I'm not sure: we need change the extension or fix the documentation? I think pg_read_all_statswould be more appropriate, but we need bump the extension version. > Thanks for exploring and confirming! I agree that pg_read_all_stats would be more appropriate. Looking at the original discussion, it seems clear that the choice of pg_monitor was intentional; see in particular https://www.postgresql.org/message-id/CA%2BOCxowV7eL-DS1Hr-h5N7Tr8Gvn5VGW%2B%2BYJ2yo6wMN9H3n9Gg%40mail.gmail.com So I think the code is correct and the documentation is a typo. That's a much easier answer to back-patch, as well. regards, tom lane
> On Feb 27, 2020, at 4:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Philip Semanchuk <philip@americanefficient.com> writes: >> On Feb 26, 2020, at 12:11 PM, Sergei Kornilov <sk@zsrv.org> wrote: >>> You are right, in contrib/pg_buffercache/pg_buffercache--1.2--1.3.sql we have >>> GRANT EXECUTE ON FUNCTION pg_buffercache_pages() TO pg_monitor; >>> GRANT SELECT ON pg_buffercache TO pg_monitor; >>> Not pg_read_all_stats. I'm not sure: we need change the extension or fix the documentation? I think pg_read_all_statswould be more appropriate, but we need bump the extension version. > >> Thanks for exploring and confirming! I agree that pg_read_all_stats would be more appropriate. > > Looking at the original discussion, it seems clear that the choice of > pg_monitor was intentional; see in particular > > https://www.postgresql.org/message-id/CA%2BOCxowV7eL-DS1Hr-h5N7Tr8Gvn5VGW%2B%2BYJ2yo6wMN9H3n9Gg%40mail.gmail.com > > So I think the code is correct and the documentation is a typo. > That's a much easier answer to back-patch, as well. Sounds good to me. Thanks for the context! Cheers Philip
Philip Semanchuk <philip@americanefficient.com> writes: >> On Feb 27, 2020, at 4:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Looking at the original discussion, it seems clear that the choice of >> pg_monitor was intentional; see in particular >> https://www.postgresql.org/message-id/CA%2BOCxowV7eL-DS1Hr-h5N7Tr8Gvn5VGW%2B%2BYJ2yo6wMN9H3n9Gg%40mail.gmail.com >> So I think the code is correct and the documentation is a typo. >> That's a much easier answer to back-patch, as well. > Sounds good to me. Thanks for the context! Re-reading the pg_buffercache documentation, I was reminded that that view can have a pretty significant performance hit if you've got lots of shared buffers. So I think being restrictive about it is good policy, reinforcing the view that the code made the right choice. I pushed a patch fixing the docs, in v10 and up. regards, tom lane