Re: copy.c handling for RLS is insecure

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: copy.c handling for RLS is insecure
Дата
Msg-id 20150727210230.GL3587@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: copy.c handling for RLS is insecure  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
All,

* Stephen Frost (sfrost@snowman.net) wrote:
> * Andres Freund (andres@anarazel.de) wrote:
> > On 2015-07-09 01:28:28 -0400, Noah Misch wrote:
> > > > - Keep the OID check, shouldn't hurt to have it
> > >
> > > What benefit is left?
> >
> > A bit of defense in depth. We execute user defined code in COPY
> > (e.g. BEFORE triggers). That user defined code could very well replace
> > the relation. Now I think right now that'd happen late enough, so the
> > second lookup already happened. But a bit more robust defense against
> > that sounds good to me.
>
> Attached patch keeps the relation locked, fully qualifies it when
> building up the query, and uses list_member_oid() to check that the
> relation's OID ends up in the resulting relationOids list (to address
> Noah's point that the planner doesn't guarantee the ordering; I doubt
> that list will ever be more than a few entries long).
>
> Also removes the misguided Assert().
>
> Barring objections, I'll commit this (and backpatch to 9.5) tomorrow.

Apologies for not pushing this before I left on vacation.  I've done so
now.
Thanks!
    Stephen

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: A little RLS oversight?
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive