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

From Michael Paquier
Subject Re: Read access for pg_monitor to pg_replication_origin_status view
Date
Msg-id 20200602044917.GB3594@paquier.xyz
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>)
List pgsql-hackers
On Mon, Jun 01, 2020 at 03:38:07PM -0300, Martín Marqués wrote:
> Took me a bit longer than expected, but here is a new version, now
> with the idea of just removing the superuser() check and REVOKEing
> execution of the functions from public. At the end I grant permission
> to functions and the pg_replication_origin_status view.
>
> I wonder now if I needed to GRANT execution of the functions. A grant
> on the view should be enough.

+GRANT EXECUTE ON FUNCTION pg_replication_origin_progress(text, boolean) TO pg_monitor;
+GRANT EXECUTE ON FUNCTION pg_replication_origin_session_progress(boolean) TO pg_monitor;

FWIW, I think that removing a hardcoded superuser() restriction and
assigning new rights to system roles are two different things, so it
would be better to split the logic into two patches to ease the
review.

I can also see the following in func.sgml:
    Use of functions for replication origin is restricted to
    superusers.

But that's not right as one can use GRANT to leverage the ACLs of
those functions with your patch.  I have a suggestion for this part,
as follows:
"Use of functions for replication origin is only allowed to the
superuser by default, but may be allowed to other users by using the
GRANT command."

Also, you may want to add this patch to the next commit fest:
https://commitfest.postgresql.org/28/
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical ()at walsender.c:2762
Next
From: Amit Kapila
Date:
Subject: Re: Small doc improvement about spilled txn tracking