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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Дата
Msg-id 29446.1485527744@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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 Haas <robertmhaas@gmail.com> writes:
> - contrib/pageinspect has lots of superuser checks, basically because
> they have known input-validation weaknesses.  See
> 3e1338475ffc2eac25de60a9de9ce689b763aced for the rationale in detail.

FWIW, I think that's a bit of an oversimplification.  There are two
components to contrib/pageinspect: get_raw_page() and a pile of page
interpretation functions.  The input-validation issue appies primarily
to the interpretation functions.

In principle, if we could make the interpretation functions completely
bulletproof, we could remove all security checks for them.  However,
they're largely useless without get_raw_page(), so it's not apparent
what's the point of doing a lot of work (and taking the risk of missing
something) unless we first get rid of get_raw_page()'s superuser check.
And that seems fraught with questions.  Maybe it'd be all right to
allow it for tables you have full read access to (can select all columns,
no RLS) but I'm not convinced.  For example, full read access doesn't
allow you to see values that were in the table in the past, before you
were granted read access ... but get_raw_page() might.
        regards, tom lane



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

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