Re: Review of Row Level Security

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

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

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company