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

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-15 01:00:03
Message-ID: 4945AC13.6000906@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> On Friday 12 December 2008 19:09:26 Alvaro Herrera wrote:
>> I don't understand -- why wouldn't we just have two columns, one for
>> plain row-level security and another for whatever security system the
>> platforms happens to offer? If we were to follow that route, we could
>> have row-level security first, extracting the feature from the current
>> patch; and the rest of PGACE could be a much smaller patch implementing
>> the rest of the stuff, with SELinux support for now with an eye to
>> implementing Solaris TX or whatever.
>
> Exactly.

It seems to me most of people (including me) can agree on the "2 security
feature and 2 security system columns" approach.
Now, I started to work the implementation based on the way here:

http://code.google.com/p/sepgsql/source/browse/#svn/trunk/sepgsql-test

It enables to support a plain row-level DAC and a selectable MAC.
So, it does not require more than two security system columns, in future also.

Please wait for a few days to see the revised version of patches.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-15 01:02:29 Re: Bug in information_schema: FK constraint is defined as against referenced table only
Previous Message Tom Lane 2008-12-15 00:47:40 Re: So, why shouldn't SET CONSTRAINTS set a transaction snapshot?