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

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Row-security on updatable s.b. views
Date: 2014-02-04 06:43:41
Message-ID: 52F08C1D.3090608@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)github(dot)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

In response to

Responses

Browse pgsql-hackers by date

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