From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
Date: | 2008-12-12 00:06:07 |
Message-ID: | 4941AAEF.7060409@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Boley | 2008-12-12 00:12:35 | Re: benchmarking the query planner |
Previous Message | Tom Lane | 2008-12-11 23:57:47 | Re: benchmarking the query planner |