Re: Review of Row Level Security

On 20 December 2012 00:24, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> I can see a use case for not having security apply for users who have
>> *only* INSERT privilege. This would allow people to run bulk loads of
>> data into a table with row security. We should add that. That is not
>> the common case, so with proper documentation that should be a useful
>> feature without relaxing default security.
>>
>> Never applying security for INSERT and then forcing them to add BEFORE
>> triggers if they want full security is neither secure nor performant.
>
> I think INSERT vs. not-INSERT is not the relevant distinction, because
> the question also arises for UPDATE.

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.

> In the UPDATE case, the question
> is whether the RLS qual should be checked only against the OLD tuple
> (to make sure that we can see the tuple to modify it) or also against
> the NEW tuple (to make sure that we're not modifying it to a form that
> we can no longer see). In other words, the question is not "do we
> support all of the commands?" but rather "do we check not only the
> tuple read but also the tuple written?". For INSERT, we only write a
> tuple, without reading. For SELECT and DELETE, we only read a tuple,
> without writing a new one. UPDATE does both a read and a write.

I'm not sure what this comment adds to the discussion. What you say is
understood.

>>> Previously, I suggested that we handle this by enforcing row-level
>>> security only on data read from the table - the OLD row, so to speak -
>>> and not on data written to the table - the NEW row, so to speak -
>>> because the latter case can be handled well enough by triggers. (The
>>> OLD case cannot, because not seeing the row is different from erroring
>>> out when you do see it.) There are other alternatives, like allowing
>>> the user to specify which behavior they want. But I think that simply
>>> decreeing that the policy will apply not only to rows read but also
>>> rows written in all cases will be less flexible than we will
>>> ultimately want to be.
>>
>> As discussed, we should add a security feature that is secure by
>> default. Adding options to make it less secure can follow initial
>> commit. We might even make it in this release if the review of the
>> main feature goes well.
>
> Saying that something is or is not secure is not meaningful without
> defining what you want to be secure against. There's nothing
> "insecure" about checking only the tuples read; it's just a different
> (and useful) threat model.

There are three main points

* "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.

* 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.

* 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.

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