Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

KaiGai Kohei wrote:
> 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.

If we cannot agree the compile-time enable/disable approach, I can prepare
to suggest a compromise draft.

This idea allows to compile two or more security mechanism in the same binary,
and adds a configuration parameter to choose a security mechanism on its startup
time. So, a single security mechanism chosen works in same time, but multiple
security mechanisms are built in compile time.
  For example, at $PGDATA/postgresql.conf    pgace_security = selinux    # for SE-PostgreSQL    pgace_security = rowacl
   # for row-level acl    pgace_security = solaristx  # for upcoming Trusted Solaris?
 

As Peter mentioned before, the reason why compile-time enable/disable approach
is not recommendable is packaging issue. It requires to deliver a single version
of binary package as far as possible. This idea does not conflict to the policy.

Again, I cannot think it is a good idea to pack several values into a field.

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