Re: Monitoring roles patch

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Monitoring roles patch
Date: 2017-03-22 13:17:30
Message-ID: 20170322131730.GD9812@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter,

* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) wrote:
> On 3/22/17 07:48, Dave Page wrote:
> > With the patch, complex monitoring systems can easily be setup with
> > something like:
> >
> > CREATE ROLE monitoring_user LOGIN;
> > GRANT pg_monitor TO monitoring_role;
>
> That assumes that we have thought of all the ways in which people might
> want to monitor things.

I disagree. The entire point of the pg_monitor role is to cover those
rights which we feel should be available to monitoring solutions, and
that *will* change over time.

> If we do it via GRANTs instead, then users can easily extend it.

The intent here is that users will *also* be able to do it via GRANTs if
they wish to.

> If we instead change the hardcoded superuser checks to hardcoded
> some-other-role checks, then the whole system instantly becomes unusable
> the moment someone wants to monitor something we haven't thought of.

Right, that's why we need specific roles for the cases where we have to
have a C-level check and the pg_monitor role should only be GRANT'd
those other roles or GRANTs on specific functions, all of which a
DBA/superuser could do themselves with their own role, if they wished to
do so, instead of using pg_monitor.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2017-03-22 13:19:22 Re: increasing the default WAL segment size
Previous Message Stephen Frost 2017-03-22 13:15:10 Re: Monitoring roles patch