Skip site navigation (1) Skip section navigation (2)

Prohibit row-security + inheritance in 9.4?

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Smith <greg(dot)smith(at)crunchydatasolutions(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Subject: Prohibit row-security + inheritance in 9.4?
Date: 2014-01-30 07:39:47
Message-ID: (view raw or flat)
Lists: pgsql-hackers
Hi all

I'm having a hard time seeing any reasonable semantics for the
combination of row-security and inheritance in 9.4 that are also
practical to implement.

I'm considering just punting on inheritance for 9.4, adding checks to
prohibit inheritance from being added to a rel with row security and
prohibiting any rel with inheritance from being given a row-security policy.

Here's why:


Earlier discussions seemed to settle on each relation having its own
row-security quals applied independently. So quals on a parent rel did
not cascade down to child rels.

That gives you a consistent view of the data in a child rel when
querying via the parent vs directly, which is good. It's surprising when
you query via the parent and see rows the parent's row-security
qualifier doesn't permit, but that surprising behaviour is consistent
with other surprising things in inheritance, like a primary key on the
parent not constraining rows inserted into children.

The trouble is that this isn't going to work when applying row-security
rules using the security barriers support. Security quals get expanded
before inheritance expansion so that they're copied to all child rels.
Just what you'd expect when querying a relation that's a parent of an
inheritance tree via a view.

It's what you'd expect to happen when querying a parent rel with
row-security, too. Parent quals are applied to children. But that then
gives you an inconsistent view of a rel's contents based on whether you
query it via a parent or directly.

I embarked upon that because of the concern that was expressed here
about the way KaiGai's row-security patch fiddles directly with
remapping attributes during planning; rebuilding row-security on top of
updatable security barrier views was seen as a cleaner approach.

So. I could:

ALTER TABLE ... SET ROW SECURITY) any parent or child rel from having
row-security policy, i.e. punt it until 9.5;

2. Do another round of security qual expansion that fetches quals from
pg_rowsecurity *after* inheritance expansion, giving us the
each-relation-stands-alone behaviour;

3. Accept the inconsistent view of child rel contents in exchange for
the otherwise sane behaviour of applying a parent's quals to children;
document that if you don't want this, don't grant users direct access to
the child tables;

4. attempt to pull quals from parents when querying a child rel directly.

I'm going to have a go at making (2) happen, but if it doesn't come
together fast, I'll just prohibit the combination of inheritance and
row-security for 9.4.  That won't upset updatable security barrier
views, only actual row-security policy. People who want row-security
over partitioned tables will just have to be patient.

 Craig Ringer         
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date

Next:From: Christian KruseDate: 2014-01-30 07:42:08
Subject: Patch: compiling the docs under Gentoo
Previous:From: Christian KruseDate: 2014-01-30 07:32:20
Subject: Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group