Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check - Mailing list pgsql-hackers

From Dave Page
Subject Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Date
Msg-id CCA91040-97A4-4075-98BE-D489A309131C@pgadmin.org
Whole thread Raw
In response to Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superusercheck  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers

> On 27 Jan 2017, at 17:39, Stephen Frost <sfrost@snowman.net> wrote:
>
> Greetings,
>
> * Simon Riggs (simon@2ndquadrant.com) wrote:
>>> On 27 January 2017 at 14:09, Dave Page <dpage@pgadmin.org> wrote:
>>>> On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs <simon@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
permissionsfor - it's the all-or-nothing approach. 

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


pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: [HACKERS] One-shot expanded output in psql using \G
Next
From: Andrew Borodin
Date:
Subject: Re: [HACKERS] pg_background contrib module proposal