Re: [HACKERS] Monitoring roles patch

On Wed, Mar 22, 2017 at 7:48 AM, Dave Page <dpage@pgadmin.org> wrote:
>> I'd be inclined to skip the rest of
>> this.  If an individual user wants to grant that bundle of privileges
>> to a role, they can do it with or without pg_monitor.
>
> GRANT cannot be used in all cases, as some of the functions changed
> have hard-coded superuser checks. In those cases, I've added
> pg_monitor membership to the permission checks in the C code.

Oh.  Well, why not just control access using the permissions checking
mechanism entirely, without hardcoding any OID?

> The reason for having the role is to minimise the amount of work
> required by the user to setup a role for the purposes of monitoring
> the server. This is a practice which is seen in other DBMSs for
> usability.
>
> With the patch, complex monitoring systems can easily be setup with
> something like:
>
> CREATE ROLE monitoring_user LOGIN;
> GRANT pg_monitor TO monitoring_role;
>
> Without, the users setting up their monitoring system will have to run
> a much more complex set of GRANTs, almost certainly requiring
> scripting.

But that script is easy to provide, probably not very long, and could
be bundled in an extension if it's helpful.  I'm wary of committing
ourselves to a specific decision about what pg_monitor includes; that
seems like it could result in endless future litigation every time
somebody wants to make a change.  In contrast, nobody's going to have
any question at all about the remit of pg_read_all_settings.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company