Ok, next step is to check that user and group 'www' exist on the system (grep www /etc/{passwd,groups} or perl -e 'print getpwnam("www"),$/,getgrnam("www"),$/'). If that turns up no problem, look again for suEXEC setup. It's not the same thing as setting the suid bit on the scripts. $ httpd -l -L -V will assist in that.
After Compline,
Zaxo
| [reply]
[d/l]
[select] |
Apache appears to have been compiled with suEXEC theoretically enabled, but the path to the suEXEC wrapper itself set wrong; there are no references to suEXEC config in the .conf files that I can find.
Am I right in thinking that the solution here is probably to recompile Apache without suEXEC??
| [reply] |
Some administrators don't like suEXEC because cgi then runs with higher privileges than 'nobody'. I am in the opposite camp. I think that security is enhanced by giving users full use of file system permissions on their site. Bad scripts can eat resources in either case, and suEXEC limits the damage one user's error can do to another user's site.
There is terse but (I believe) complete documentation of proper suEXEC setup in the Apache manual.
After Compline,
Zaxo
| [reply] |