Re: Read access for pg_monitor to pg_replication_origin_status view - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Read access for pg_monitor to pg_replication_origin_status view
Date
Msg-id 20200604.161033.1845732016784727041.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Read access for pg_monitor to pg_replication_origin_status view  (Martín Marqués <martin@2ndquadrant.com>)
Responses Re: Read access for pg_monitor to pg_replication_origin_status view
List pgsql-hackers
Hi, Martin.

At Wed, 3 Jun 2020 13:32:28 -0300, Martín Marqués <martin@2ndquadrant.com> wrote in
> Hi Kyotaro-san,
>
> Thank you for taking the time to review my patches. Would you like to
> set yourself as a reviewer in the commit entry here?
> https://commitfest.postgresql.org/28/2577/

Done.

> > 0002:
> >
> > It is forgetting to grant pg_read_all_stats to execute
> > pg_show_replication_origin_status.  As the result pg_read_all_stats
> > gets error on executing the function, not on doing select on the view.
>
> Seems I was testing on a cluster where I had already been digging, so
> pg_real_all_stats had execute privileges on
> pg_show_replication_origin_status (I had manually granted that) and
> didn't notice because I forgot to drop the cluster and initialize
> again.
>
> Thanks for the pointer here!

Sorry for not mentioning it at that time, but about the following diff:

+GRANT SELECT ON pg_replication_origin_status TO pg_read_all_stats;

system_views.sql already has a REVOKE command on the view. We should
put the above just below the REVOKE command.

I'm not sure where to put the GRANT on
pg_show_replication_origin_status(), but maybe it also should be at
the same place.

> > 0003:
> >
> > It seems to be a take-after of adminpack's documentation, but a
> > superuser is not the only one on PostgreSQL.  The something like the
> > description in 27.2.2 Viewing Statistics looks more suitable.
> >
> > > Superusers and members of the built-in role pg_read_all_stats (see
> > > also Section 21.5) can see all the information about all sessions.
> >
> > Section 21.5 is already saying as follows.
> >
> > > pg_monitor
> > >   Read/execute various monitoring views and functions. This role is a
> > >   member of pg_read_all_settings, pg_read_all_stats and
> > >   pg_stat_scan_tables.
>
> I'm not sure if I got this right, but I added some more text to point
> out that the pg_read_all_stats role can also access one specific
> function. I personally think it's a bit too detailed, and if we wanted
> to add details it should be formatted differently, which would require
> a more invasive patch (would prefer leaving that out, as it might even
> mean moving parts which are not part of this patch).
>
> In any case, I hope the change fits what you've kindly pointed out.

I forgot to mention it at that time, but the function
pg_show_replication_origin_status is a function to back up
system-views, like pg_stat_get_activity(), pg_show_all_file_settings()
and so on. Such functions are not documented since users don't need to
call them. pg_show_replication_origin_status is not documented for the
same readon. Thus we don't need to mention the function.

In the previous comment, one point I meant is that the "to the
superuser" should be "to superusers", because a PostgreSQL server
(cluster) can define multiple superusers. Another is that "permitted
to other users by using the GRANT command." might be obscure for
users. In this regard I found a more specific description in the same
file:

  Computes the total disk space used by the database with the specified
  name or OID.  To use this function, you must
  have <literal>CONNECT</literal> privilege on the specified database
  (which is granted by default) or be a member of
  the <literal>pg_read_all_stats</literal> role.

So, as the result it would be like the following: (Note that, as you
know, I'm not good at this kind of task..)

  Use of functions for replication origin is restricted to superusers.
  Use for these functions may be permitted to other users by granting
  <literal>EXECUTE<literal> privilege on the functions.

And in regard to the view, granting privileges on both the view and
function to individual user is not practical so we should mention only
granting pg_read_all_stats to users, like the attached patch.

> > 0004:
> >
> > Looks fine by me.
>
> Here goes v3 of the patch

By the way, the attachements of your mail are out-of-order. I'm not
sure that that does something bad, though.

--
Kyotaro Horiguchi
NTT Open Source Software Center

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 700271fd40..66679e8045 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -11009,8 +11009,10 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
   <para>
    The <structname>pg_replication_origin_status</structname> view
    contains information about how far replay for a certain origin has
-   progressed.  For more on replication origins
-   see <xref linkend="replication-origins"/>.
+   progressed.  Use of this view is restricted to superusers and
+   pg_read_all_stats role.  To use this view, you must be a member of
+   the <literal>pg_read_all_stats</literal> role. For more on replication
+   origins see <xref linkend="replication-origins"/>.
   </para>
 
   <table>

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Atomic operations within spinlocks
Next
From: Juan Fuentes
Date:
Subject: Possible bug on Postgres 12 (CASE THEN evaluated prematurely) -Change of behaviour compared to 11, 10, 9