Re: Updates of SE-PostgreSQL 8.4devel patches

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Date: 2008-09-26 00:29:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Here is how I think SQL-level row permissions would work:
> > We already have an optional OID system column that can be specified
> > during table creation (WITH OIDS). We could have another optional oid
> > column (WITH ROW SECURITY) called security_context which would store the
> > oid of the role that can see the row; if the oid is zero (InvalidOid),
> > anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
> > use the oid to look up strings in pg_security.
> This is just a different syntax for KaiGai's label storage
> implementation. It doesn't really answer any of the hard questions,
> like what the heck is the behavior of foreign keys.

Well, the PGACE documentation says:

Datum pgacePreparePlanCheck(Relation rel)

It is invoked just before calling a function which implements fereign
key constraint.

The major purpose of this hook is to keep consistency in the lowest
level. It enables to notify the guest the beginning of checks in foreign
key constraint. The guest can change the behavior of tuple level access
control between pgacePreparePlanCheck() and pgaceRestorePlanCheck().

--> In SE-PostgreSQL case, access controls in tuple level are normally done
with filtering any violated tuple. However, it can prevent to check
foreign key constraint, because caller cannot recognize whether no tuple
refers the primary relation, or any tuple refering are filtered.
Therefore, SE-PostgreSQL aborts the current transaction if any violated
tuple refering the primary relation.

Bruce Momjian <bruce(at)momjian(dot)us>

+ If your life is a hard drive, Christ can be your backup. +

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2008-09-26 00:32:21 Re: Updates of SE-PostgreSQL 8.4devel patches
Previous Message Robert Haas 2008-09-26 00:28:43 Re: Updates of SE-PostgreSQL 8.4devel patches