Re: Review of Row Level Security

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.

> * 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? There's something
notationally appealing about being able to apply a security policy to
a table rather than creating a separate view and telling people to use
the view in lieu of the table, but how much is that notational
convenience worth? It has some value from the standpoint of
compatibility with other database products ... but probably not a
whole lot, since all the syntax we're inventing here is
PostgreSQL-specific anyway. Your proposal to check both tuples read
and tuples written might add some value ... but unless there's an
as-yet-undemonstrated performance benefit, it is again mostly a
notational benefit.

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