Re: [v9.3] Row-Level Security - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: [v9.3] Row-Level Security
Date
Msg-id CAEZATCVKpJmf7BDQps8rzwgo0k9Ei6u9i12RaLX-s8bEEY+eAw@mail.gmail.com
Whole thread Raw
In response to Re: [v9.3] Row-Level Security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.3] Row-Level Security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List pgsql-hackers
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;


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.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Proof of concept: auto updatable views
Next
From: Jeff Janes
Date:
Subject: Re: [PERFORM] pg_dump and thousands of schemas