Re: Allowing to create LEAKPROOF functions to non-superuser

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Allowing to create LEAKPROOF functions to non-superuser
Дата
Msg-id 341912.1618864356@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Allowing to create LEAKPROOF functions to non-superuser  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Allowing to create LEAKPROOF functions to non-superuser
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 16, 2021 at 3:57 AM Noah Misch <noah@leadboat.com> wrote:
>> Hence, I do find it reasonable to let pg_read_all_data be sufficient for
>> setting LEAKPROOF.  I would not consult datdba, because datdba currently has
>> no special read abilities.  It feels too weird to let BYPASSRLS start
>> affecting non-RLS access controls.  A reasonable person may assume that
>> BYPASSRLS has no consequences until someone uses CREATE POLICY.  That said, I
>> wouldn't be horrified if BYPASSRLS played a part.  BYPASSRLS, like
>> pg_read_all_data, clearly isn't something to grant lightly.

> I agree that datdba doesn't seem like quite the right thing, but I'm
> not sure I agree with the rest. How can we say that leakproof is a
> non-RLS access control? Its only purpose is to keep RLS secure, so I
> guess I'd be inclined to think that of the two, BYPASSRLS is more
> closely related to the topic at hand.

Umm ... I'm pretty sure LEAKPROOF also affects optimization around
"security barrier" views, which I wouldn't call RLS.  Out of these
options, I'd prefer granting the ability to pg_read_all_data.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Allowing to create LEAKPROOF functions to non-superuser
Следующее
От: James Coleman
Дата:
Сообщение: Re: "could not find pathkey item to sort" for TPC-DS queries 94-96