Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154310 - Web data under /srv problematic.
Summary: Web data under /srv problematic.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-09 17:44 UTC by Noa Resare
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-11 10:52:50 UTC


Attachments (Terms of Use)

Description Noa Resare 2005-04-09 17:44:31 UTC
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

Comment 1 Daniel Walsh 2005-04-11 10:52:50 UTC
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 10:59:00 UTC
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 11:16:01 UTC
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

Comment 4 Daniel Walsh 2005-04-11 11:25:33 UTC
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 11:35:42 UTC
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.