Re: Read access for pg_monitor to pg_replication_origin_status view

From: Martín Marqués <martin(at)2ndquadrant(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Read access for pg_monitor to pg_replication_origin_status view
Date: 2020-06-04 12:17:18
Message-ID: CAPdiE1wUt3WQZq30Wa1Xz0NM7rtVPZdK15PKRd0zS3ugZsCsow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Kyotaro-san,

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

Yes, I agree that it makes the revoking/granting easier to read if
it's grouped by objects, or groups of objects.

Done.

> 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:

OK, now I understand what you were saying. :-)

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

I did some re-writing of the doc, which is pretty close to what you
proposed above.

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

That's likely Gmail giving them random order when you attach multiple
files all at once.

New patches attached.

Regards,

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
v4-0001-Access-to-pg_replication_origin_status-view-has-r.patch text/x-patch 3.0 KB
v4-0002-We-want-the-monitoring-role-pg_read_all_stats-to-.patch text/x-patch 1.5 KB
v4-0003-Change-replication-origin-function-documenation-t.patch text/x-patch 1.2 KB
v4-0004-Apply-changes-to-the-documentation-to-reflect-tha.patch text/x-patch 1.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2020-06-04 12:25:10 Re: what can go in root.crt ?
Previous Message Mahendra Singh Thalor 2020-06-04 11:35:50 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions