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
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):
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
4. add some content and fire up apache
Apache returns and logs permission denied
The added content (the same result as when running apache with 'setenforce 0')
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?
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.