Re: Review of Row Level Security

2012/12/20 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Not sure I understand you. You suggested it was a valid use case for a
>> user to have only INSERT privilege and wish to bypass security checks.
>> I agreed and suggested it could be special-cased.
>
> That's not really what I intended to suggest. I view checking an
> inserted tuple and checking the new version of an updated tuple as of
> a piece. I would think we would check against the RLS quals in either
> both of those situations or neither, not one without the other.
>
>> * "Applies to all commands" should not be implemented via triggers.
>> Complex, slow, unacceptable thing to force upon users. Doing that begs
>> the question of why we would have the feature at all, since we already
>> have triggers and barrier views.
>
> I agree that it is questionable whether we need this feature given
> that we already have security barrier views. I don't agree that
> performing security checks via triggers is unacceptably slow or
> complex. Rather, I would say it is flexible and can meet a variety of
> needs, unlike this feature, which imposes much tighter constraints on
> what you can and cannot check and in which situations.
>
I'd like to ask Simon which point is more significant; performance
penalty or complex operations by users.
If later, FK constraint is a good example that automatically defines
triggers that applies its checks on inserted tuple and newer version
of updated tuple.
Even though we need to consider how to handle dynamically added
row-security policy by extension (e.g sepgsql), I don't think we need
to enforce users to define triggers for each tables with row-security
as long as system support it.

>> * the default for row security should be "applies to all commands".
>> Anything else may be useful in some cases, but is surprising to users
>> and requires careful thought to determine if it is appropriate.
>
> I (and several other people, it seems) do not agree.
>
>> * How to handle asymmetric row security policies? KaiGai has already
>> begun discussing problems caused by a security policy that differs
>> between reads/writes, on his latest patch post. That needs further
>> analysis to check that it actually makes sense to allow it, since it
>> is more complex. It would be better to fully analyse that situation
>> and post solutions, rather than simply argue its OK. Kevin has made
>> good arguments to show there could be value in such a setup; nobody
>> has talked about banning it, but we do need analysis, suggested
>> syntax/mechanisms and extensive documentation to explain it etc.
>
> Frankly, in view of your comments above, I am starting to rethink
> whether we want this at all. I mean, if you've got security barrier
> views, you can check the data being read. If you've got triggers, you
> can check the data being written. So what's left?
>
In some cases, it is not a reasonable choice to re-define kind of
database objects or its name from what existing application assumes.
It is a reason why we need adaptive security features on regular
tables without or minimum application changes....

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>