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>