Re: Row-security on updatable s.b. views - Mailing list pgsql-hackers

On 02/04/2014 02:43 PM, Craig Ringer wrote:
> On 01/30/2014 04:05 PM, Craig Ringer wrote:
>> On 01/30/2014 01:25 PM, Craig Ringer wrote:
>>> On 01/29/2014 09:47 PM, Craig Ringer wrote:
>>>> https://github.com/ringerc/postgres/compare/rls-9.4-upd-sb-views
>>>>
>>>> i.e. https://github.com/ringerc/postgres.git ,
>>>>      branch rls-9.4-upd-sb-views
>>>>
>>>> (subject to rebasing) or the non-rebased tag rls-9.4-upd-sb-views-v2
>>>
>>> Pushed an update to the branch. New update tagged
>>> rls-9.4-upd-sb-views-v3 . Fixes an issue with rowmarking that stems from
>>> the underlying updatable s.b. views patch.
>>>
>>> Other tests continue to fail, this isn't ready yet.
>>
>> Specifically:
> 
>> - row-security rule recursion detection isn't solved yet, it just
>> overflows the stack.
> 
> This is now fixed in the newly tagged rls-9.4-upd-sb-views-v4 in
> git@github.com:ringerc/postgres.git .

Based on Tom's objections, another approach is presented in
rls-9.4-upd-sb-views-v5 on  git@github.com:ringerc/postgres.git . The
Query node is used to record the recursive expansion parent list
instead, and copying is avoided.

However, I've separately tracked down the cause of the test failures like:

ERROR:  could not open file "base/16384/30135": No such file or directory

This occurs where a row-security qual is declared to use a view.
Row-security quals get stored without rewriting (which is necessary, see
below). The qual is injected into securityQuals and expanded, but *not
rewritten*. So the executor sees an unexpected view in the tree.

Because a view RTE has its relid field set to the view's oid, this
doesn't get picked up until we try to actually scan the view relation in
the executor.

(I'd like to add Asserts to make the executor fail a bit more
informatively when you try to scan a view, but that's separate.)


So, that's clearly broken. There are really two possible solutions:

1. Try (again) to do row-security in the rewriter. This was previously
impossible because of the definition of row-security behaviour around
inheritance, but with the simplified inheritance model now proposed I
think it's possible.

2. Invoke RewriteQuery from within expand_security_quals, rewriting the
query after security qual expansion. This is only needed for
row-security; for updatable s.b. views rewriting has happened with
recursion into securityQuals during the original rewrite pass.


I suspect that (2) will result in a resounding "yuck".

So I have to see if I can now turn around *again* and plug row-security
into the rewriter after all.  That's a pretty frustrating thing to
discover in mid-late CF4.

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