Re: Updates of SE-PostgreSQL 8.4devel patches

Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.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:
> 
>     http://code.google.com/p/sepgsql/wiki/WhatIsPGACE
>     
>     Datum pgacePreparePlanCheck(Relation rel)

In the latest patch, this hooks is replaced by pgaceBeginPerformCheckFK()
and pgaceEndPerformCheckFK(), but its purpose is unchanged.

Sorry for the confusable legacy description.

> -->    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. 

Yes, this behavior keeps FK consistency.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>