The attached patch is a refreshed version towards the latest master branch,
to fix up patch conflicts.
Here is no other difference from the previous revision.
Thanks,
2012/9/5 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> 2012/9/3 Kohei KaiGai <kaigai@kaigai.gr.jp>:
>> 2012/9/2 Dean Rasheed <dean.a.rasheed@gmail.com>:
>>> On 17 July 2012 05:02, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>>> 2012/7/17 Robert Haas <robertmhaas@gmail.com>:
>>>>> On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>>>>> The attached patch is a revised version of row-level security feature.
>>>>>> ...
>>>>>> According to the Robert's comment, I revised the place to inject
>>>>>> applyRowLevelSecurity(). The reason why it needed to patch on
>>>>>> adjust_appendrel_attrs_mutator() was, we handled expansion from
>>>>>> regular relation to sub-query after expand_inherited_tables().
>>>>>> In this revision, it was moved to the head of sub-query planner.
>>>>>>
>>>
>>> Hi,
>>>
>>> I had a quick look at this and spotted a problem - certain types of
>>> query are able to bypass the RLS quals. For example:
>>>
>>> SELECT * FROM (SELECT * FROM foo) foo;
>>>
>>> since the RLS policy doesn't descend into subqueries, and is applied
>>> before they are pulled up into the main query. Similarly for views on
>>> top of tables with RLS, and SRF functions that query a table with RLS
>>> that get inlined.
>>>
>>> Also queries using UNION ALL are vulnerable if they end up being
>>> flattened, for example:
>>>
>>> SELECT * FROM foo UNION ALL SELECT * FROM foo;
>>>
>> Thanks for your comment.
>>
>> Indeed, I missed the case of simple sub-queries and union-all being
>> pulled up into the main query. So, I adjusted the location to invoke
>> applyRowLevelSecurity() between all the pull-up stuff and expanding
>> inherited tables.
>>
>> The attached patch is a fixed and rebased revision for CF:Sep.
>>
> Sorry! I attached incorrect revision. The attached patch is right one.
>
> Thanks,
> --
> KaiGai Kohei <kaigai@kaigai.gr.jp>
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
