Re: [v9.4] row level security - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [v9.4] row level security
Date
Msg-id 52E1CC04.8040907@2ndquadrant.com
Whole thread Raw
In response to Re: [v9.4] row level security  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [v9.4] row level security
List pgsql-hackers
(Re-sending; I forgot to cc the list)

On 01/20/2014 02:15 PM, Craig Ringer wrote:
> On 01/20/2014 09:58 AM, Craig Ringer wrote:
>> As it is I'm spending today reworking the RLS patch on top of the new
>> approach to updatable security barrier views.
>
> To get that rolling I've split the RLS patch up into chunks, so we can
> argue about the catalogs, ALTER syntax, and the actual row-filtering
> implementation separately ;-)
>
> It's currently on git@github.com:ringerc/postgres.git in the branch
> rls-9.4-split, which is subject to rebasing. I'm still going through it
> making sure each chunk at least compiles and preferably passes "make
> check".

That branch is now pretty stable, and passes checks at every stage up to
the new RLS regression tests. I've pushed a new version to branch
rls-9.4-split. Further updates will rebase this branch.

The tag rls-9.4-split-v5 identifies this particular push, and won't get
rebased away.

I found a number of merge errors and problems that I've corrected and
incorporated into the history, including a bad pg_class.h edit, a
missing break; in tablecmds.c, a missing Node* assignment in the parser
grammar for RESET ROW SECURITY, etc.

A number of concerns remain outstanding, including those Greg listed
except for the regression tests, which I've fixed, and rebasing on top
of current master.

-Continue to expand the functional tests

-Is there enough information about row security available in psql
 output?  For example, there's nothing in "\d" output that suggests it
 might exist.  pg_rowsecurity is a monster to try and read.

-Documentation needs plenty of editing, which I can take care of.


Additionally, the issue I found earlier remains outstanding:

- Fails to deal with user-id change during portal execution in (eg)
  SECURITY DEFINER funcs returning refcursor, or SQL cursors open
  across SET SESSION AUTHORIZATION. `current_user` returns value
  after change, not original value, causing issues with RLS predicates.


Now that the patch is split up into stages I'm going to work on
replacing patches 7 and 8 (query plan transformation, COPY support) with
an approach based on Dean's updaable security barriers code.

If anyone else picks up work on this, **please** try to keep this patch
series intact, or even better, move the regression tests back into the
relevant patches as you go. If you send an updated version of the RLS
patch please send a git ref too; that'll make it much easier to pull
your changes and integrate them into the relevant patch in the series
with appropriate "git rebase --interactive" (ab)use.



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


Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Why do we let autovacuum give up?
Next
From: Claudio Freire
Date:
Subject: Re: Why do we let autovacuum give up?