Re: [v9.4] row level security

On Wed, Nov 6, 2013 at 6:38 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> That's the approach I've been considering. There are a few wrinkles with
> it, though:
>
> (a) Updatable views are implemented in the rewriter, not the planner.
> The rewriter is not re-run when plans are invalidated or when the
> session authorization changes, etc. This means that we can't simply omit
> the RLS predicate for superuser because the same rewritten parse tree
> might get used for both superuser and non-superuser queries.
>

Incidentally I still feel this is at root the problem with updateable views
in general. I know it's a bit off to be tossing in concerns from the peanut
gallery when I'm not actually offering to work on it and others are having
putting in serious efforts in this area and having some success. So take
this for what it's worth...

I think the right approach for updateable views would be to support a
syntax like this in the planner:

UPDATE (select * from tab1,tab2 ...) WHERE tab1.id = .. SET ...

Then updateable views would just rewrite the query mechanically the way
regular views work by substituting the view definition in place of the view
name. Since all the work would be done in the planner it would have access
to the same kinds of information that regular join planning etc have.

I'm not sure if this solves all the problems with RLS but it would solve
the concern about plan invalidations and I think it would make it simpler
to reason about security rules that are otherwise happening at plan time.

--
greg