Tom Lane wrote: > Even if we were to accept the SEPostgres patches lock stock and barrel > tomorrow, I don't foresee that it will ever get to the point of being > useful except to an extremely small group of users who are driven by > extreme need. Nobody else is going to have the motivation needed to > develop custom security policies, and there simply isn't any chance > of anyone developing any generally useful default policy. Red Hat's > policy has been trying to cope with cases like "which directories should > Apache be allowed to read, *given that it's running a Red-Hat-standard > configuration*?" That's far more circumscribed than any useful database > policy would be, because database applications aren't nearly that > standardized.
Basically, it is the last option to write custom policy modules for users, and it is not a recommendable for average users. The default security policy contains various kind of pre-defined security contexts, and it allows administrators to assign them dirs/files according to their purpose. In most cases, user can complete SELinux setups with customizations nowadays, not writing their custom policy modules. For example, the default security policy intend to web contents are stored in "/var/www/html" labeled as "httpd_sys_content_t" which allows web-servers read-only access to the files. If we want to store web contents in "/opt/html", all we have to do is: $ chcon -R system_u:object_r:httpd_sys_content_t:s0 /opt/html It changes the security context of the /opt/html and files under the directory. It performs as web-contents from perspective of SELinux. We can apply similar configuration on database objects. For example, we want to have a read-only table from confined processes, all we have to do is: CREATE TABLE read_only_tbl ( x int, y text ) SECURITY CONTEXT ('system_u:object_r:sepgsql_ro_table_t:s0'); The "sepgsql_ro_table_t" is a type which allows confined processes only SELECT contents from the table, and it is provided by the default security policy. We don't need to write any custom security policy in typical use cases. SELinux has been integrated into RedHat/Fedora since FC2. It had a lot of matters in the early phase. For example, the default security policy was troubled, user needed to modify the security policy and rebuild whole of the policy, here were no custmization parameters, ... However, these matters have been resolved for the recent years. It seems to me your complaints based on the legacy SELinux. 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