Re: Review of Row Level Security

2012/12/20 Stephen Frost <sfrost(at)snowman(dot)net>:
> Kevin, all,
>
> * Kevin Grittner (kgrittn(at)mail(dot)com) wrote:
>> The more secure behavior is to allow entry of data which will not
>> be visible by the person doing the entry.
>
> wrt this- I'm inclined to agree with Kevin. It's certainly common in
> certain environments that you can write to a higher level than you can
> read from. Granting those writers access to read the data later would
> be... difficult.
>
> What we're really arguing about here, afaict, is what the default should
> be. In line with Kevin's comments and Tom's reading of the spec (along
> with my own experience in these environments), I'd argue for the default
> to allow writing rows you're not allowed to read.
>
If system ensures writer's permission is always equivalent or more restrictive
than reader's permission, it also eliminates the problem around asymmetric
row-security policy between commands.
The problematic scenario was that updatable but invisible rows are exposed;
using update with returning clause for example. In case when updatable
rows are always visible, here is no matter even if user shows it.
Probably, we can implement it as ((row-security of select) AND (row-security
of update)) that ensures "always restrictive row-security policy".

Thanks,

> It would certainly be ideal if we could support both options, on a
> per-relation basis, when we release the overall feature. It doesn't
> "feel" like it'd be a lot of work to do that, but I've not been able to
> follow this discussion up til now. Thankfully, I'm hopeful that I'm
> going to have more time now to keep up with PG. :)
>
> Thanks,
>
> Stephen
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>