Re: [v9.3] Row-Level Security

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: [v9.3] Row-Level Security
Дата
Msg-id CAEZATCVKpJmf7BDQps8rzwgo0k9Ei6u9i12RaLX-s8bEEY+eAw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.3] Row-Level Security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Ответы Re: [v9.3] Row-Level Security
Список 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 по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: Proof of concept: auto updatable views
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: [PERFORM] pg_dump and thousands of schemas