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

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> I updated the patch set of SE-PostgreSQL (revision 1268).
>>
>> [1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1268.patch
>> [2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1268.patch
>> [3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1268.patch
>> [4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1268.patch
>> [5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1268.patch
>> [6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1268.patch
>>
>> Draft of the SE-PostgreSQL documentation is here:
>>   http://wiki.postgresql.org/wiki/SEPostgreSQL
>>
>> List of updates:
>> - The patches are rebased to the CVS HEAD.
>> - RelOptions related hooks are cleaned up.
>> - The Row-level ACL feature is chosen in default.
>> - rowacl_table_default() is added to show the default ACL of the table.
>> - The initial revision of regression test for Row-level ACL is added.
>>
>> If you have anything to comment for the patches, could you disclose it?
>> It is not necessary to be a comprehensive one. Don't hesitate to submit.
> 
> I looked over the patch and was wondering why you chose to have a
> configure option to disable row-level ACLs.

There are no explicit reasons.
I thought it was natural, as if we can build Linux kernel without any
enhanced security features (SELinux, SMACK and so on).

I don't oppose to elimination of "--disable-row-acl" options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.

> I assume that could just be always enabled.

It is not "always" enabled. When we build it with SE-PostgreSQL feature,
rest of enhanced security features (includes the row-level ACL) are
disabled automatically, as we discussed before.

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