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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Дата
Msg-id CA+TgmoZt8EYhK5XcjW5W_H9-UdLBT2--8qZGJ-nfHJdiwSGwLA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
On Fri, Jan 27, 2017 at 8:18 AM, Simon Riggs <simon@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check