> On 27 Jan 2017, at 17:39, Stephen Frost <sfr...@snowman.net> wrote:
> Greetings,
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>>> On 27 January 2017 at 14:09, Dave Page <dp...@pgadmin.org> wrote:
>>>> On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>>>> If the monitoring tool requires superuser then that is a problem, so
>>>> it would be helpful if it didn't do that, please. Not much use having
>>>> a cool tool if it don't work with the server.
>>> Sure, that's what I want - to provide the management and monitoring
>>> capabilities without requiring superuser. Limiting the capability of
>>> the tools is not an option when you talk to users - however for some
>>> of them, having to use full superuser accounts is a problem as well
>>> (especially for those who are used to other DBMSs that do offer more
>>> fine-grained permissions).
> Right, I'm all about providing fine-grained permissions and granting
> those out to monitoring users, but we need to have an understanding of
> what the monitoring really needs (and doesn't need...) to be able to
> ensure that the fine-grained permission system which is built matches
> those needs and allows the admin to grant out exactly the rights needed.
>>>> The management and monitoring tool could be more specific about what
>>>> it actually needs, rather than simply requesting generic read and
>>>> write against the filesystem. Then we can put those specific things
>>>> into the server and we can all be happy. Again, a detailed list would
>>>> help here.
>>> Agreed - I do need to do that, and it's on my (extremely long) list.
>>> I'm just chiming in on this thread as requested!
> That would certainly be really nice to have.  I have some ideas, and
> I've been meaning to try and work towards them, but knowing what other
> monitoring systems do would be great.
>> So I think it would be useful to have two modes in tools, one where
>> they know they have superuser and one where they know we don't have
>> it. At least we'll know we can't do certain things rather than just
>> have them fail.
> Having such a flag in monitoring tools where it makes sense sounds
> reasonable to me, though there isn't really anything different for the
> backend to do to support this (I don't think..?).

No, that's exactly what we don't want, because then users cannot do anything 
that we can currently grant them permissions for - it's the all-or-nothing 

What we currently do is allow users to try every thing, then let the backend 
complain if it wants, and relay the access denied message to the user.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to