On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 27 January 2017 at 12:56, Dave Page <dpage@pgadmin.org> wrote:
>
>> Probably the most common complaint I get from users
>> regarding the management & monitoring tools I work on is that they
>> have to use superuser accounts to get the full benefits, unlike other
>> DBMSs where you can create a role with just the required privileges
>> (or indeed, other DBMSs that ship with such roles pre-defined for
>> convenience).
>
> This is still just the Adminpack argument. This has been going on for
> about a decade? Longer.
Not entirely. Some simple examples:
- Controlling recovery. This is fixed in 9.6+, but prior to that,
granting execute privs on pg_xlog_replay_pause() and/or
pg_xlog_replay_resume() would be accepted but wouldn't work.
- Access to certain GUCs. For example, it could be argued that "SHOW
log_directory" is quite reasonable for a monitoring tool to run, for
the purposes of auditing/alerting admins to any changes made by a
rogue superuser.
- ALTER SYSTEM - clearly there is a use case for allow certain users
to configure the database server, but not necessarily have the full
rights of a superuser that would allow them access to all the data
(yeah, I know that separation is far more complex than that alone, but
I hope you get the point).
> 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).
> 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!
> Does the latest version of pgadmin provide access to log files? I
> can't see much that really needs Adminpack anymore, though I've not
> done a thorough analysis at all.
Not yet.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
