Description of problem: The FHS mandates that /srv should be used for "Data for services provided by this system", for example data served from an apache web server (see http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM) However, using /srv for data served by apache with fc3 with selinux is less than straight forward because of the security context type set on /srv Version-Release number of selected component (if applicable): selinux-policy-targeted-1.17.30-2.94 How reproducible: always Steps to Reproduce: 1. create a dir with web content under for example /srv/www 2. point your apache DocumentRoot to this dir 3. set the right security context type on the newly created dir with 'chcon -t httpd_sys_content_t /srv/www' as described in http://fedora.redhat.com/docs/selinux-apache-fc3/ 4. add some content and fire up apache Actual results: Apache returns and logs permission denied Expected results: The added content (the same result as when running apache with 'setenforce 0') Additional info: Setting the security context type of /srv to the same as for example /opt with 'chcon -t usr_t /srv' fixes this problem
Since the standard does not specify any structure under the /src directive, we can not automatically label files here. The proper way to fix your problem was to chcon -t usr_t /srv (Or maybe, var_t) chcon -t httpd_sys_content_t /src/www
I know how to fix my problem. What I don't understand is why /opt is more "prepared" to host files served by apache (creating a subdir and marking it with http_sys_content_t works) than /srv when /srv according to the FHS is the correct place to put such files while /opt is not.
Ok, I will add context for /srv. Should it be usr_t or var_t? I guess if it is supposed to be readonly it should be usr_t? Dan
How about # # /srv # /srv(/.*)? system_u:object_r:usr_t /srv/([^/]*/)?www(/.*)? system_u:object_r:httpd_sys_content_t /srv/([^/]*/)?ftp(/.*)? system_u:object_r:ftpd_anon_t /srv/([^/]*/)?rsync(/.*)? system_u:object_r:ftpd_anon_t
The rationale in FHS linked above specifically mentions writeable data, so I think var_t is a better choice, otherwise your suggestion looks fine to me.