Horton

Thread

Commits

  1. Doc: correct thinko in pg_buffercache documentation.

  1. BUG #16279: Permissions doc incorrect for pg_buffercache

    The Post Office <noreply@postgresql.org> — 2020-02-26T16:46:18Z

    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 $

  2. Re: BUG #16279: Permissions doc incorrect for pg_buffercache

    Sergei Kornilov <sk@zsrv.org> — 2020-02-26T17:11:26Z

    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 would be more appropriate, but we need bump the extension version.

regards, Sergei

  3. Re: BUG #16279: Permissions doc incorrect for pg_buffercache

    Philip Semanchuk <philip@americanefficient.com> — 2020-02-27T21:13:17Z

    
> 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 would 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. 

Cheers
Philip

  4. Re: BUG #16279: Permissions doc incorrect for pg_buffercache

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-02-27T21:31:34Z

    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_stats would 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

  5. Re: BUG #16279: Permissions doc incorrect for pg_buffercache

    Philip Semanchuk <philip@americanefficient.com> — 2020-02-27T21:39:04Z

    
> 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_stats would 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

  6. Re: BUG #16279: Permissions doc incorrect for pg_buffercache

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-02-28T16:47:52Z

    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