Apache CGI scripts - how to run them cleanly

[Lars Poulsen]

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