From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Monitoring roles patch |
Date: | 2017-03-22 12:47:24 |
Message-ID: | CA+TgmoZ5zs50mEzALJqp3qBMC+CdT0ccnjvNJt1Ojiu9rz35zw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 22, 2017 at 7:48 AM, Dave Page <dpage(at)pgadmin(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-03-22 12:47:40 | Re: Partition-wise join for join between (declaratively) partitioned tables |
Previous Message | Ashutosh Bapat | 2017-03-22 12:46:40 | Re: Partition-wise join for join between (declaratively) partitioned tables |