Tom Lane wrote:
> "Andrew Dunstan" <andrew@dunslane.net> writes:
>> What's more, we have a SoC project for column level access controls.
>
> ... which presumably wouldn't involve any added dependency on outside code.
> For people who are already using SELinux or Trusted Solaris, making the
> database dependent on that infrastructure might be seen as a plus, but
> I'm not sure the rest of the world would be pleased.
The most significant purpose of PGACE and SE-PostgreSQL is integration
between database and operating system security policy, on mandatory
access controlled (MAC) system especially.
Thus, not to provide any regression is the most desired behavior of
PGACE on non-MAC system like SELinux disabled Linux, I think.
PGACE without using SELinux or Trusted Solaris does not give any effect,
because it is defined as static inline function with no operation mostly.
> There are also
> some interesting questions about SQL spec compliance and whether a
> database that silently hides some rows from you will give semantically
> consistent results.
Any violated tuples are always filtered from result set, before using them,
as if an additional condition is appended onto WHERE or JOIN ON clause.
The condition means whether client has enough permission on this tuple, or not.
All those processes are done after rewriting phase, so result set is constant
even if a table is referred via views.
Thus, client can deal a table as if it does not contain any violated tuples.
# If a result set contains any violated tuple, it's a bug of SE-PostgreSQL.
An exception is foreign key implementation. It internally uses UPDATE query
to support 'ON UPDATE CASCADE' rule and so on.
If violated tuples are filtered, the FK constraint is not kept.
For example, when there are five tuples to be cascaded but client does not
have enough permission onto two of them, the two tuple will be remained
without cascading.
In SE-PostgreSQL, whole of transaction will be aborted, if client does not
have enough permissions on all the tuples cascaded under FK processing.
One more exception is TRUNCATE statement. In SE-PostgreSQL, TRUNCATE statement
is nonsense, because it is translated into unconditional DELETE statement to
avoid removing tuples without enough permission.
Currently, I have not gotten any inconsistency in the access control model.
But any pointed out is welcome.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>