Re: [v9.4] row level security

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: 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: [v9.4] row level security
Date: 2014-01-24 02:12:20
Message-ID: 52E1CC04.8040907@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)github(dot)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 Content-Type Size
0001-RLS-Make-plan-caching-dependent-on-user-ID.patch text/x-patch 5.3 KB
0002-RLS-add-pg_rowsecurity-catalog.patch text/x-patch 26.3 KB
0003-RLS-Add-rowsec_relid-to-ResultRelInfo.patch text/x-patch 4.4 KB
0004-Add-ALTER-TABLE-commands-for-row-security.patch text/x-patch 12.7 KB
0005-RLS-pg_dump-support-for-dumping-rowsecurity-catalogs.patch text/x-patch 13.9 KB
0006-RLS-psql-support-for-reporting-row-security-constrai.patch text/x-patch 1.4 KB
0007-RLS-Enforce-row-security-by-transforming-query-plans.patch text/x-patch 45.6 KB
0008-RLS-Enforce-row-security-on-COPY.patch text/x-patch 4.8 KB
0009-RLS-Regression-tests.patch text/x-patch 43.2 KB
0010-RLS-Supplimental-docs.patch text/x-patch 7.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2014-01-24 02:22:54 Re: Why do we let autovacuum give up?
Previous Message Craig Ringer 2014-01-24 01:38:55 Re: Why do we let autovacuum give up?