Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) - Mailing list pgsql-hackers

Peter Eisentraut wrote:
> On Thursday 11 December 2008 18:24:54 KaiGai Kohei wrote:
>> Peter Eisentraut wrote:
>>> On Thursday 11 December 2008 17:09:25 Tom Lane wrote:
>>>> I think there should be only *one* underlying column and that it should
>>>> be manipulable by either SQL commands or selinux.  Otherwise you're
>>>> making a lie of the primary argument for having the SQL feature at all.
>>> Well, an SQL-manipulated row security column will probably have a content
>>> like
>>>
>>>     {joe=rw/bob,staff=r/bob}
>>>
>>> An SELinux-aware row security column will probably have a content like
>>>
>>>    blah_t:foo_t:quux_t
>>>
>>> And a Solaris TX-aware security column will probably have a content like
>>>
>>>    Classified
>>>
>>> How can we stick all of these in the same column at the same time?
>> To choose it on compile-time option is the most simple approach.
> 
> As mentioned before, compile-time options to choose between these variants in 
> a mutually exlusive manner is not acceptable.
> 
> Plus, using two of these together, or even three, is certainly useful and 
> reasonable in some uses.

Sorry, we have been deep midnight for the last several hours.

Packing two or more stuff into one field gives us several unignorable pains.
I cannot agree this approach. One field should be hold one value.
However, I found out it is an independent issue whether the feature should
be enabled/disabled on compile-time.

* A pain for user-interface

Currently, we allow users to update security context of tuples, as follows:
  UPDATE t SET security_context = 'system_u:object_r:sepgsql_table_t' WHERE a < 10;

But, if the "security_context" hold both of security context and row-level acls,
the above operation means setting a new security context and clear its acls
because it does not contain acl part.
It requires users to pay carefull mention to keep integrity of security attribute
for both security mechanism.
It is the heaviest pain which is never acceptable.

* A pain for performance

SE-PostgreSQL assigns a default security context for newly inserted tuples.
It is defined at in-kernel security policy, and preliminarily translated to
security identifier on userspace cache. SE-PostgreSQL fetch the cache entry
with O(1) steps, so we can decide what security identifier should be attached
so quickly.
Row-level ACL can assign default ACLs for newly inserted tuples. It is also
held as a security identifier, not a text representation. So, we can decide
what security identifier should be attached so quickly.

But, if two or more security mechanism shares a single data field, it is not
simple. When SE-PostgreSQL and Row-level ACL work at same time, it has to
extract these default security identifier to text format, combine it, lookup
pg_security, and assign matched security identifier.
It will give us awful pain.

* A pain for code complexity
No need to say.

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