Re: Arguable RLS security bug, EvalPlanQual() paranoia

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Arguable RLS security bug, EvalPlanQual() paranoia
Дата
Msg-id CAM3SWZR4wB9ShMiEoAt=4whaFzB7qt-nFdi-Jnxgk2CTkOATgg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Arguable RLS security bug, EvalPlanQual() paranoia  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Arguable RLS security bug, EvalPlanQual() paranoia  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Список pgsql-hackers
On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Thoughts?  Trying to keep it straight-forward and provide a simple
> solution for users to be able to address the issue, if they're worried
> about it.  Perhaps this, plus an additional paragraph which goes into
> more detail about exactly what's going on?

I'm still thinking about it, but I think you have the right idea here.

However, as the docs put it when talking about conventional access
controls and SELECT: "The use of FOR UPDATE or FOR SHARE requires
UPDATE privilege as well [as SELECT privilege] (for at least one
column of each table so selected)". I wonder if RLS needs to consider
this, too.

If you can just say that you don't have to worry about this when the
user has no right to UPDATE or DELETE the rows in the first place,
that makes it more practical to manage the issue. ISTM that as things
stand, you can't say that because RLS does not consider SELECT FOR
UPDATE special in any way.

-- 
Peter Geoghegan



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Arguable RLS security bug, EvalPlanQual() paranoia
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );