On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 27 January 2017 at 12:56, Dave Page <dp...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
