Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
