On 01/28/2014 02:11 PM, Craig Ringer wrote:
>> > My first thought is to add a boolean flag to RangeTblEntry (similar to
>> > the "inh" flag) to say whether RLS expansion is requested for that
>> > RTE. Then set it to false on each RTE as you add new RLS quals to it's
>> > securityQuals.
> That's what I was getting at with adding flags to RangeTblEntry, yes.
>
> Given the number of flags we're growing I wonder if they should be
> consolodated into a bitmask, but I'll leave that problem for later.
>
> I'll do this part first, since it seems you agree that a RangeTblEntry
> flag is the appropriate path. That'll make row-security checking work
> and make the patch testable.
>
> It won't deal with recursive rules, they'll still crash the backend.
> I'll deal with that as a further step.
>
I've put together a working RLS patch on top of updatable security
barrier views.
It has some known issues remaining; it doesn't do recursion checking
yet, and it fails some of the regression tests in exciting ways. I'm
looking into them step by step.
Some differences in the tests behaviours that have changed due to the
inheritance rules changing; many appear to be oversights or bugs yet to
be chased down.
You can find it here;
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
The guts of the patch appear as a diff, attached, but it's not
standalone so I suggest using git.
I'll be looking into recursion issues and the test failures tomorrow.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services