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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
