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
Type: ---
Embargoed:


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.