KaiGai Kohei wrote:
I understood objections for "enable/disable something on compile-time" approach. The following items are my revised proposal. It does not conflicts to the policy Peter said before in this thread.Items to be revised: - It allows to compile multiple security mechanis within a single binary. - It provides "--enable-selinux" configure option to build SELinux support, but the Row-level ACLs is always built because it does not require any platform specific libraries and so on. - User choose one (or no) security mechanism on initdb and postmaster starting up via $PGDATA/postgresql.conf. The current available options are selinux, rowacl and nothing. (*) What should be the default? rowacl? or, nothing? The modified initdb interface is as follows: $ initdb --pgace-security=(selinux|rowacl|nothing) - It add a new system column for security purpose. It enables to store a security attribute of tuple, so working security mechanism has to handle it properly. For example, SE-PostgreSQL handles a tuple without valid security context as a "unlabeled_t" tuple.
In addition, - The new security conlumn has common name for each security mechanisms. Candidates are "security_attr", "security_attribute", "sec_attr" or "security". At first, I start it with "security_attr".
- The security mechanism can control whether the new tuple has its security field, or not. If no security field is necessary, t_infomask is not set HEAP_HASSECURITY bit, and it does not consume any additional storage space. 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
