Re: [v9.3] Row-Level Security

On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> The attached patch is a revised version of row-level security feature.
>
> I added a feature to invalidate plan cache if user-id was switched
> between planner and optimizer. It enabled to generate more optimized
> plan than the previous approach; that adds hardwired "OR superuser()".
>
> Example)
> postgres=# PREPARE p1(int) AS SELECT * FROM t1 WHERE x > $1 AND f_leak(y);
> PREPARE
> postgres=# EXPLAIN (costs off) EXECUTE p1(2);
> QUERY PLAN
> -----------------------------------
> Seq Scan on t1
> Filter: (f_leak(y) AND (x > 2))
> (2 rows)
>
> postgres=# SET SESSION AUTHORIZATION alice;
> SET
> postgres=> EXPLAIN (costs off) EXECUTE p1(2);
> QUERY PLAN
> ---------------------------------------------
> Subquery Scan on t1
> Filter: f_leak(t1.y)
> -> Seq Scan on t1
> Filter: ((x > 2) AND ((x % 2) = 0))
> (4 rows)
>
> On the other hand, I removed support for UPDATE / DELETE commands
> in this revision, because I'm still uncertain on the implementation that I
> adopted in the previous patch. I believe it helps to keep patch size being
> minimum reasonable.
> Due to same reason, RLS is not supported on COPY TO command.
>
> According to the Robert's comment, I revised the place to inject
> applyRowLevelSecurity(). The reason why it needed to patch on
> adjust_appendrel_attrs_mutator() was, we handled expansion from
> regular relation to sub-query after expand_inherited_tables().
> In this revision, it was moved to the head of sub-query planner.
>
> Even though I added a syscache entry for pg_rowlevelsec catalog,
> it was revised to read the catalog on construction of relcache, like
> trigger descriptor, because it enables to reduce cost to parse an
> expression tree in text format and memory consumption of hash
> slot.
>
> This revision adds support on pg_dump, and also adds support
> to include SubLinks in the row-level security policy.

This revision is too late for this CommitFest; I've moved it to the
next CommitFest and will look at it then, or hopefully sooner.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company