Suexec is DEAD


#1

I had a CGI script break on otto this morning. Upon investigation, I found it was because the web server was now running as “dhapache” rather than as my username as it had before.

To quickly fix this and get things working again, I changed the directory permissions to 777 and the file permissions to 666…which the CGI documentation says NOT to do.
https://panel.dreamhost.com/kbase/index.cgi?area=144&keyword=777
(scroll down to “Special considerations because we run suexec!”)

It says, “your CGI scripts on your web site run as though they were run by your user and group!” This is no longer the case.

It was working fine until sometime last night when the server was changed so that CGI scripts are run as user “dhapache” rather than my username. When that changed, the forum CGI scripts broke because they suddenly didn’t have permission to write/change files anymore.

What really has me worried is if you turn suexec back on again, this will break again because “As a security precaution, suexec REQUIRES that all cgi scripts AND THE DIRECTORIES IN WHICH THEY RESIDE NOT be writable by anyone but the owner user.” …and I’ll have to go change all the file and directory permissions back to what they were before.

Pain. In. The. Ass!

I opened a ticket. It was about 13 hours before I got a response. The response just told me it looks like my script is working again. I don’t think Brian even looked into the details I provided…so now I have to explain the whole problem AGAIN and wait again for another stupid response. (It seems like the first responses are always trying to blow me off until I insist there IS a problem.)


#2

I’ve not heard of anything like this happening. Seemed to be working OK for you until about 6:30 this morning. I did setup a test perl script (test/test1.cgi on your main domain), and I can confirm that it’s running as the Apache user:

dhapache 16244 19583 0 22:57 ? 00:00:00 /usr/bin/perl /home/xx/xx/test/test1.cgi

Not really my area of expertise, but I did send this link to the rest of our technical staff. Do me a favor, and open a new support request (if you don’t have an open one now) and request that they pass it on to the admin team - I’ll make sure someone fixes this (for real, and for good) and gets back to you. You’ll also want to ask them to do a find / chown on all the files owned by dhapache after it’s fixed.

After poking around some more, I see now what the problem is more or less - the user and group need to be specified in the httpd config file, but they aren’t for some reason (they are on most of the other Apache instances that I checked on that machine).


#3

Sorry for the self followup - I think I’ve fixed it now; please do let us know right away if it happens again.

I changed the ownership too, but you may need to fix up some stray permissions; I did a:
find . -type d -perm 0777 | xargs chmod 0755
find . -type f -perm 0666 -exec chmod 0644 {} ;

I think this should fix them up for the most part.