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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Дата
Msg-id 20170125191345.GN9812@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> Also, the same argument could be made about removing the built-in
> superuser check from ANY function, and we've already rejected that
> argument for a bunch of other functions.  If we say that argument is
> valid for some functions but not others, then we've got to decide for
> which ones it's valid and for which ones it isn't, and consensus will
> not be forthcoming.  I take the position that hard-coded superuser
> checks stink in general, and I'm grateful to Stephen for his work
> making dump/restore work properly on system catalog permissions so
> that we can support better alternatives.  I'm not asking for anything
> more than that we apply that same policy here as we have in other
> cases.

I went over *every* superuser check in the system when I did that work,
wrote up a long email about why I made the decisions that I did, posted
it here, had follow-on discussions, all of which lead to the patch which
ended up going in.

I am not anxious to revisit that decision and certainly not based on
an argument that, so far, boils down to "I think a monitoring system
might be able to use this function that allows it to read pg_authid
directly, so we should drop the superuser() check in it."

Thanks!

Stephen

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: 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