This is a very common problem, with a wide array of reasons.
For this example, we have a cgi called admin.cgi that won’t run from the browser.
First, you want to make sure the cgi is executable. Almost all cgi’s should be
chmod 755. To find out, log into the shell (as the user with the cgi problem or as root)
and go to the directory the cgi is in. Type “ls -al admin.cgi”; this will show you what the permissions
are for the cgi in question.
# ls -al
total 6
drwxr-xr-x 2 burst wheel 512 May 29 16:04 .
drwxr-xr-x 3 burst wheel 512 May 29 16:03 ..
-rw-r—r— 1 burst wheel 41 May 29 16:04 admin.cgi
Here we see that the cgi does not have proper permissions. Currently, it’s chmod 644, which means
readble by everyone and writable only by the owner and not executable by anyone.
To fix this is easy, simple type “chmod 755 admin.cgi”. Now when we look at the permissions, we see this..
# ls -al
total 6
drwxr-xr-x 2 burst wheel 512 May 29 16:04 .
drwxr-xr-x 3 burst wheel 512 May 29 16:03 ..
-rwxr-xr-x 1 burst wheel 41 May 29 16:04 admin.cgi
Now that the cgi has the proper permissions (the last x means executable by anyone), we can try to bring it up
in our browser again.
Still returning a 500 error, not working ?
Let’s see if it is a coding problem..
Type “perl -w ./admin.cgi”; this turns on warnings
and will let us know whether or not it’s an error in the actuall code itself.
# perl -w ./admin.cgi
Can’t find string terminator ’”’ anywhere before EOF at ./admin.cgi line 3.
Now we see that, for now, the perl script won’t run because it has fatal errors in it.
How to fix errors in code is far, far beyond the scope of this FAQ. There are numerous
tutorials on perl and troubleshooting specific errors available on the internet, try
searching google.com .
Assuming we found the error in the code, let’s try to run it from the command line again.
# perl -w ./admin.cgi
Hello World !
Great, our script works, however it can still not work in a browser. How is this possible ?
Two reasons are common for this. One is that the cgi is not sending the correct Content-type
to the browser. In our script, the admin.cgi won’t work in a browser eventhough it will from
the shell. To fix, we add the following lines near the top of the script.
print “Content-type: text/htmlnn”;
So now when we run the script, the first line we see is like this:
# perl -w ./admin.cgi
Content-type: text/html
Hello World !
Now, our script has to work right ?!
Nope, if it’s still not working in the browser, it’s quite possible it’s the fault
of the second reason, su_exec.
su_exec is often built into the Apache webserver as a security measure. It forces sanity checking
on the permissions of CGI scripts before running them, then forces them to run with the permissions
of the account owner. When checking for proper permissions, there are a few things we want to look for.
# ls -la
total 6
drwxr-xr-x 2 burst wheel 512 May 29 16:04 .
drwxr-xr-x 3 burst wheel 512 May 29 16:03 ..
-rwxr-xr-x 1 burst wheel 78 May 29 16:24 admin.cgi
The directory ”.” is the current working directory. This must be chmod 755, though it might be tempting to chmod
the cgi-bin 777 as well as the cgi’s, it opens up the ability of someone else on the server to save whatever they
want to in the directory. If the cgi is chmod 777 (or 775 for that matter), it would allow anyone on the server
to be able to edit that cgi and change the code. The ramifications of this can be quite serious, such as saving credit
card numbers to a text file for the ‘attacker’ to read later. The cgi must also be chmod 755 or su_exec will kill it
before sending it to the browser. Traditionally, the su_exec log file is /usr/local/apache/logs/suexec_log .
If you are unsure about problems with a cgi, this is a good place to look. You might want to tail -f the log file
then try to load the cgi in your browser (hitting reload a few times won’t hurt) to see wheat the exact error is for
the cgi. You should also check to see that the file is owned by the user of the account. Sometimes when a passwd or group
file get’s corrupted, you will see a number rather than a username.
# ls -la
total 6
drwxr-xr-x 2 8840 8840 512 May 29 16:04 .
drwxr-xr-x 3 burst wheel 512 May 29 16:03 ..
-rwxr-xr-x 1 8840 8840 78 May 29 16:24 admin.cgi
In this case, you would want to chown the cgi AND the directory back to it’s rightful owner by typing
“chown burst.burst *” . Even if it looks correct, it is possible for it to have the name correct yet be
associated with a different UID. This will show up in the suexec_log, and you use the same fix as if it had a different
UID alltogether.
Still won’t work ? Put in a support ticket so we can take a look at it !
