Re: [v9.3] Row-Level Security

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.

> FWIW I recently developed some similar code as part of a patch to
> implement automatically updatable views
> (http://archives.postgresql.org/pgsql-hackers/2012-08/msg00303.php).
> Some parts of that code may be useful, possibly for adding
> UPDATE/DELETE support.
>
Let me check it.

Best regards,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>