Re: Review of Row Level Security

On 9 December 2012 06:21, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 2012/12/7 Simon Riggs <simon(at)2ndquadrant(dot)com>:
>> On 5 December 2012 11:16, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>
>>>> Oracle defaults to putting VPD on all event types: INSERT, UPDATE,
>>>> DELETE, SELECT. ISTM we should be doing the same, not just say "we can
>>>> add an INSERT trigger if you want".
>>>>
>>>> Adding a trigger just begs the question as to why we are bothering in
>>>> the first place, since this functionality could already be added by
>>>> INSERT, UPDATE or DELETE triggers, if they are a full replacement for
>>>> this feature. The only answer is "ease of use"
>>>>
>>>> We can easily add syntax like this
>>>>
>>>> [ROW SECURITY CHECK ( .... ) [ON [ ALL | INSERT, UPDATE, DELETE, SELECT [..,]]]]
>>>>
>>>> with the default being "ALL"
>>>>
>>> I think it is flaw of Oracle. :-)
>>
>> Agreed
>>
>>> In case when user can define leakable function, it enables to leak contents
>>> of invisible rows at the timing when executor fetch the rows, prior to
>>> modification
>>> stage, even if we allows to configure individual row-security policies
>>> for SELECT
>>> and DELETE or UPDATE commands.
>>> My preference is one policy on a particular table for all the commands.
>>
>> Yes, only one security policy allowed.
>>
>> Question is, should we offer the option to enforce it on a subset of
>> command types.
>>
>> That isn't anything I can see a need for myself.
>>
> It is not hard to support a feature not to apply security policy on
> particular command types, from implementation perspective.
> So, my preference is to support only the behavior corresponding
> to above "ALL" option, then support per commands basis when
> we got strong demands.
> How about your thought?

Very much agree that ALL should be the default, and only option for
first commit of this feature.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services