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>