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

From Craig Ringer
Subject Re: Row-security on updatable s.b. views
Date
Msg-id 52F08C1D.3090608@2ndquadrant.com
Whole thread Raw
In response to Re: Row-security on updatable s.b. views  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Row-security on updatable s.b. views  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Row-security on updatable s.b. views  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
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 .

I landed up adding a field to RangeTblEntry that keeps track of all the
oids of relations row-security expanded to produce this RTE. When
testing an RTE for row-security policy, this list is checked to see if
the oid of the relation being expanded is already on the list. The list
is copied to all RTEs inside sublinks after a relation is expanded using
a query_tree_walker.

> - COPY doesn't know anything about row-security

COPY will ERROR on row-security rels in rls-9.4-upd-sb-views-v4.

I'm looking at integrating the approach Kohei KaiGai took in the
original patch now, then I'll be moving on to:

> - I'm just starting to chase some odd errors in the tests, "ERROR:
> failed to find unique expression in subplan tlist" and "ERROR:  could
> not open file "base/16384/30070": No such file or directory". Their
> cause/origin is not yet known, but they're specific to when row-security
> policy is being applied.

I was hoping these would be fixed by solving the recursion issues, but
that wasn not the case.

Input/comments would be appreciated. I haven't looked into this yet.

> - policies based on current_user don't "remember" current_user when rows
> are pulled from refcursor returned by a security definer function.

This is actually a separate, existing bug, or surprising behaviour. I'd
like to address it, but it's really a separate patch.


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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Retain dynamic shared memory segments for postmaster lifetime