The box itself doesn't run a DNS. I didn't think it was required as running the script from the command line works (and I can use web browsers from it with no problem).
Would there be a difference between command line vs cgi that required a DNS be installed locally? | [reply] |
The DNS server need not be on your machine, the question was whether DNS name resolution works at all. Since it works on the command line (on that machine) there is still the question whether maybe the web server can't access DNS. Security features like SELinux, SuSEs AppArmor or a chrooted apache environment might hinder the cgi script from accessing the DNS server or other web servers.
| [reply] |
In the case of a chrooted web server, it should be sufficient to copy /etc/hosts into the "etc" directory in the chroot. The path of the chroot can be determined (on Linux) by ls -l /proc/1234/root, where 1234 is the pid of the web server.
| [reply]
[d/l] |
I've investigated this problem a bit more, as seeing as two monks had the problem, I'd expect it to be more widespeard as more people upgrade.
Someone can move this to a more appropriate section if required
This problem is definatly related to SELinux
I've installed FC9 as a test on WMware, which by default has SELinux installed. SELinux adds extra labels to every file to see if Apache can access them. So not only
do permissions control your access, but also SELinux, which is part of the Kernel.
Running that test program:
#!/bin/bash
host=$(/usr/bin/host maps.google.com)
cat <<!
Content-Type: text/plain
system (`ls -l /usr/bin/host`);
$host
!
If you then look in
cat /var/log/messages<br>
you'll see something like:
Sep 22 10:16:02 localhost setroubleshoot: SELinux is preventing ho
+st (httpd_sys_script_t) "create" to <Unknown> (httpd_sys_script_t). F
+or complete SELinux ....
Now, the easy solution is to disable SELinux. Tempting. Very tempting. But bad.
To see if SELinux is currently on:
cat /selinux/enforce
If you get a '1' back, it's on.
If you disable it and run that test program again, you'll see it works now under cgi!
to disable it, log in as root:echo 0 >/selinux/enforce
access the test cgi program via a web browser, and it should now work.
to reenable itecho 1 >/selinux/enforce
thanks for spotting the typo Jethro
Do not turn it off for any length of time, as a total relabeling of the system will be required
The above instructions put it into permissve mode, which, it you just do it quickly, shouldn't affect your security too much.
From the doco,
"Detailed Description:
SELinux denied access requested by host. It is not expected that this access is
required by host and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access."
SELinux doco also states clearly that applications should be fixed to work with SELinux, rather than disabling the OS security mechanism.
I'd say that those modules (LWP, etc) that access DNS would need to put out some sort of permission error if it is denied...
Basically,you can see the extra SELinux labels on files by: ls -Z *
In the case of /usr/bin/host, you get exe="/usr/bin/host" subj=unconfined_u:system_r:httpd_sys_script_t:s0
it is not owned or accessible to any cgi scripts. For that to happen, they need to have
httpd_sys_script_exec_t permissions...or a local exclusion policy.
SELinux is blocking httpd processes from connecting to the net (probably to stop hackers from attacking other machines from httpd)
Because I'm running short of time now, this sledge hammer approach will fix that:setsebool -P httpd_can_network_connect 1
The better way is to generate a local exclusion policyaudit2allow -a
see http://www.crypt.gen.nz/selinux/faq.html#BSP.3 for more info on doing this... I've spent enough time on it...Life is too short for SELinux
hope this helps. | [reply]
[d/l]
[select] |