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