On Fri, Jan 27, 2017 at 8:18 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > This is still just the Adminpack argument. This has been going on for > about a decade? Longer.
Right. > 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. The argument keeps going on because users aren't willing to give up some of the monitoring capabilities that currently require functionality which is arbitrarily restricted to superusers, and not everyone here is willing to recognize those monitoring needs as legitimate. I believe we should take it as a given that any check somebody's bothered building into a popular monitoring tool like check_postgres.pl is probably a good check written by a smart developer, and the question we should ask ourselves here is "what can we do in the core project to let those checks run without needing superuser privileges?". Instead, we say things like... > 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. ...which basically means we think the current checks are written is a way that is wrong, and should be changed to use some not-yet-invented alternative mechanism. But that's position is a bit arrogant and a bit counterfactual. It's counterfactual because the functions in question NOT give generic read and write access against the filesystem; they are limited to the data directory and the log directory. IOW, significant efforts have already been made to impose reasonable security precautions. More could be done, but particularly with regards to basically-harmless things like pg_ls_dir() and pg_stat_file(), there's no real security benefit to doing so. (I agree that there could be some benefit for pg_read/write_file, but the question in my mind is how much complexity it's worth adding for a corner case; I'd be fine with a new mechanism if it's relatively simple.) And it's arrogant because it supposes that we know better than the tool authors what the right way to do everything is. If Greg Sabino Mullane has had a check that uses pg_ls_dir() in check_postgres.pl for ten years, it's probably a great way of checking the thing that he's using it to check, because Greg Sabino Mullane is a smart, experienced, long-time community member. Any argument to the contrary -- especially one offered only in the context of trying to make that check work without requiring superuser privileges -- seems to me to be Monday-morning-quarterbacking (apologies for the Americanism; I don't know what the equivalent British expression would be). -- Robert Haas EnterpriseDB: 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
