Re: Row-security on updatable s.b. views

On 03/04/2014 09:41 PM, Yeb Havinga wrote:
> On 04/03/14 02:36, Craig Ringer wrote:
>>
>> I've pushed an update to the branch with the fix for varno handling.
>> Thanks. It's tagged rls-9.4-upd-sb-views-v8 .
>>
>> I've almost run out of time to spend on row security for this
>> commitfest, unfortunately. I'm putting a blog together with a current
>> status update. Frustrating, as it's coming together now.
>>
>> Open issues include:
>>
>> - Passing plan inval items from rewriter into planner
>> - COPY support pending
>> - Clear syntax in DDL
>>
>> Most of the rest are solved; it's actually looking pretty good.
>
> Hi Craig,
>
> I've tested the results from the minirim.sql that was posted earlier,
> and the v8 gives the same results as v4 :-)

Good to hear.

The main known issue remaining is plan invalidation. Row security needs
to create PlanInvalItems during _rewrite_ and also needs to set a
PlannerGlobal field for the user ID the plan depends on. If it fails to
do this then the superuser will sometimes run queries and have
row-security applied, non-superusers might skip row security when it
should be applied. This seems to be the cause of foreign key check
issues I've observed, too.

That's not trivial, because right now the rewriter only returns a Query
node. It doesn't have anywhere to stash information that's global across
the whole query, and adding fields to Query for the purpose doesn't seem
ideal, since it's also used for subqueries, and in the planner. Changing
the rewriter to return a RewriteResult struct that contains the Query
and some other global info would be very intrusive, though, as it'd
affect all the plan cache and invalidation machinery and the various
rewriter/planner call sites.

I've also got some concerns about the user visible API; I'm not sure it
makes sense to set row security policy for row reads per-command in
PostgreSQL, since we have the RETURNING clause. Read-side policy should
just be "FOR READ". Initially I think we should be using triggers to
enforce write side policy, which should raise errors if you try to
insert/update/delete the wrong thing. Could move to something working a
bit more like WITH CHECK OPTION later.

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