# TREE rawhide-20041007 # ARCH i386 I have httpd serving up public_html/ for a local user. That user has FollowSymlinks turned on in httpd.conf. I am running a CGI web tool written in python that attempts to access the symlink. With selinux enabled the CGI fails in what boils to to EPERMDENIED. raceback (most recent call last): File "index.cgi", line 12, in ? template.display("index.tmpl") File "/home/jlaska/public_html/TemplateClass.py", line 141, in display print self.header() File "/home/jlaska/public_html/TemplateClass.py", line 118, in header return Template( file=tmplfile, searchList= [self.vars] ) File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line 156, in __init__ self.compile(source, file) File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line 235, in compile self._fileMtime = os.path.getmtime(file) File "/usr/src/build/445495-i386/install/usr/lib/python2.3/posixpath.py", line 146, in getmtime return os.stat(filename).st_mtime OSError: [Errno 13] Permission denied: '/home/jlaska/public_html/templates/redhat.com/header.tmpl' The file that is getting the permission denial above is accessable by python when run outside of apache (from a shell). The file is a symlink that points to another file within the users public_html/ (~/public_html)> ls -Z templates/default/header.tmpl -rw-r--r-- jlaska jlaska system_u:object_r:httpd_user_content_t templates/default/header.tmpl (jlaska@flatline)-(3/pts/5)-(10/07/2004 03:23pm)- (~/public_html)> ls -Z templates/redhat.com/header.tmpl lrwxrwxrwx jlaska jlaska user_u:object_r:httpd_sys_content_t templates/redhat.com/header.tmpl -> ../default/header.tmpl The interesting thing is that when I point my web browser to the symlink directly...it loads fine. However, when I point the web browser to the cgi script that loads the symlink, it fails with selinux denial messages: Oct 7 13:42:06 flatline kernel: audit(1097170926.811:0): avc: denied { read } for pid=13875 exe=/usr/bin/python name=header.tmpl dev=hda2 ino=272895 scontext=root:system_r:httpd_suexec_t tcontext=user_u:object_r:httpd_sys_content_t tclass=lnk_file Oct 7 13:42:06 flatline kernel: audit(1097170926.946:0): avc: denied { search } for pid=13875 exe=/usr/bin/python name=src dev=hda3 ino=1788293 scontext=root:system_r:httpd_suexec_t tcontext=system_u:object_r:src_t tclass=dir It was able to resolve the denials by appending the following rules to domains/misc/later.te : allow httpd_suexec_t httpd_sys_content_t:lnk_file { read }; allow httpd_suexec_t src_t:dir { search }; It also appears I'm able to get by with only the first rule: allow httpd_suexec_t httpd_sys_content_t:lnk_file { read };
Wait...are you running in permissive mode? How do you have a CGI script running as httpd_suexec_t?? That's very wrong, only /usr/sbin/suexec should be running in that domain.
What is the label on the CGI script? Can you do: ls -adZ /path/to/your/script.cgi
Created attachment 104911 [details] src/policy/domains/misc/later.te I have other rules in my later.te that were suggested to get me to a point were I could use selinux and this CGI. (~)> ls -adZ public_html/index.cgi -rwxr-xr-x jlaska jlaska system_u:object_r:httpd_user_content_t public_html/index.cgi*
allow httpd_suexec_t file_t:file { create execute execute_no_trans getattr ioctl read unlink write }; allow httpd_suexec_t httpd_sys_content_t:file { execute execute_no_trans getattr ioctl read }; These rules ccompromise the security of httpd_suexec_t; it should only be allowed to execute specifically labeled files. In this case, the correct fix is to change the label on your CGI script to allow httpd_suexec_t to execute it: chcon -t httpd_sys_script_exec_t ~jlaska/public_html/index.cgi Many other rules in your later.te are symptoms of other problems as well. Can you try starting over without later.te and seeing whether relabeling the CGI script allows the desired access? Incidentally I'd suggest putting system CGI scripts somewhere under /var/www, and only allowing user CGI scripts like ~jlaska/public_html to be httpd_user_script_exec_t.