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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
