Re: Arguable RLS security bug, EvalPlanQual() paranoia

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Arguable RLS security bug, EvalPlanQual() paranoia
Дата
Msg-id 20150929220650.GJ3685@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Arguable RLS security bug, EvalPlanQual() paranoia  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Ответы Re: Arguable RLS security bug, EvalPlanQual() paranoia  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Список pgsql-hackers
* Adam Brightwell (adam.brightwell@crunchydatasolutions.com) wrote:
> On Mon, Aug 3, 2015 at 6:21 PM, Peter Geoghegan <pg@heroku.com> wrote:
> > 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.
>
> I have attached a patch for review that I believe addresses the
> documentation side of this issue.
>
> Thoughts or comments?

I'm not convinced this is the right place, but at a minimum it should be
referenced from the RLS documentation.  Further, it should be noted that
users who have direct SQL access can control what the isolation level
is for their transaction.

Also, isn't it possible to avoid this by locking the records?  If the
locking fails or blocks then you know another user has those records
locked and you don't update or you wait until you hold the lock.
Assuming that works (I don't immediately see why it wouldn't..), we
should provide an example.

Thanks!

Stephen

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: No Issue Tracker - Say it Ain't So!