Bug 154310 - Web data under /srv problematic.
Web data under /srv problematic.
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-04-09 13:44 EDT by Noa Resare
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-11 06:52:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Noa Resare 2005-04-09 13:44:31 EDT
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):

How reproducible:

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
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
Comment 1 Daniel Walsh 2005-04-11 06:52:50 EDT
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
Comment 2 Noa Resare 2005-04-11 06:59:00 EDT
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.
Comment 3 Daniel Walsh 2005-04-11 07:16:01 EDT
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?

Comment 4 Daniel Walsh 2005-04-11 07:25:33 EDT
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
Comment 5 Noa Resare 2005-04-11 07:35:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.