At 01:16 PM 5/4/2010, Dominick Grift wrote: >First i would like to say that i would not host websites from /home/*. In my first message in this thread I gave some background and explained why I was doing this. I REALLY do not want content to live in my root partition; I want to be free to wipe the root partition when I do a version upgrade on the operating system (once per year or so). >Secondly, you should use the semanage plus fcontext option to make >your file context specifications persistent. When I am all done with the process of making my system work (understanding what the things are than can be tuned under the "targeted" policy, my next project may well be to learn how to make my own tweaks to policy in a way that is compatible across updates to the system policies. Right now, that seems to be several levels up on my learning curve. Despite 20 years of working part time with *nix system administration (my first Unix experience was on a version 7 unix with BBN's ARPAnet patches) I am still struggling with all the "new" stuff, including SELinux. While it may be a good thing to tweak filecontexts with semanage, it seems to me that minor tweaks like this should be perfectly fine to make "permanent" by invoking them from a file that is included from /etc/rc.local at startup time. If I do "permanent" changes interactively from the command line, it becomes hard to keep track of them so they can be done again afgter a system version upgrade. >But i you want to use /home/* to host websites then i guess >httpd_sys_content_t would be a good type for its webroot like it is >for /var/www. >The issue here is that a directory at inode # 2 on device dm-7 is >labeled user_home_dir_t and that the httpd_sys_script_t domain is >not allowed to read it. One of the sub-problems here is that I really do not know what device "dm-7" is. /home is mounted on a "partition" created by LVM (Logical Volume Manager). On a "df" command or a "mount" display it shows up as /dev/mapper/VolGroup00-SystemHome. I am guessing it is the same. But ls -Zd /home gives the label as system_u:object_r:home_root_t:s0 Is it possible that ls -Z and SELinux (runtime) have different notions of what is in the inode ? >Either you allow it or you label the dir at inode 2 on dm-7 with a >type that apache can search. Other than by tweaking the label, how could I allow it ? And what are the types that apache can search ? Is there a list of them in a file in the source RPM for policy-targeted ? Is a user expected to recompile the policy or even read the source ? Is there a manual with this information ? I have been doing lots of googling for pages that might contain information about this stuff, but without much success. I did find http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch20_:_The_Apache_Web_Server which was quite useful (section "Security Contexts For CGI Scripts"), but I still do not understand why apache would need "search" access (does that mean directory read operations ?) for /home/ in order to launch a perl script located in /home/httpd/cgi-bin/. One article I read says this is actually a false error: The script will run just fine ev en if SELinux is enforcing, and it suggests you just use "noaudit" to suppress the denial messages about it. Lars Poulsen -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
