If you have trouble understanding "chmod" for
goodness sakes, buy a UNIX book! Permissions can often be a real
drag. Many systems have funky automatic settings that you need to
override if you are to allow the world (web browsers) to utilize your
scripts.
Permissions are UNIX's (If you are using an NT or Mac web server,
you probably don't need to worry about this) way of allowing or
disallowing various people access to files on them. Permissions are
set by using the chmod, chown and chgrp command. For the most part
though, you will only need to worry about the chmod command.
To find out what permissions your files are set to, type "ls -l
-g" at the UNIX command line.
You'll probably receive something like (if not, type man ls and
figure out how your setup works)...
eff.org:~/Fortune$ ls -l -g
total 237
-rw-rw-r-- 1 selena doc 607 Oct 9 17:14 README.txt
drwxrwxr-x 2 selena doc 512 Apr 6 10:05 Test/
-rw-rw-r-- 1 selena doc 2065 Jan 29 07:37 eff_quotes
-rw-rw-r-- 1 selena doc 104434 Oct 9 17:14 fortunes
-rw-rw-r-- 1 selena doc 106720 Oct 9 17:14 fortunes.dat
eff.org:~/Fortune$
The permissions can be seen in the part of the line which
looks like -rw-rw-r-- The part is divided into four sections.
directory or file?, User permissions, group permissions and
world permissions. In this case you can see that Test is a
directory "d" it can be read, written to and executed (that is,
we can read files within that directory) by user and group
"rwxrwx" and can be read and executed by world "r-x".
fortunes.dat is a file "-" and can be read and written to by user
and group "rw-rw" and can only be read by world "r--".
My general rule for web permissions is to begin by setting "all"
files and directories to chmod 777. This is the most insecure,
but if your scripts work at this level, but do not work
otherwise, you have isolated the problem to a permissions
problem. Then, one by one, increase the security. I usually
jump to chmods 775, then 755, etc. for directories and scripts
and 666, then 664, then 644, etc. for files. The idea is to
narrow things down until you have the most secure setting.
But, make sure that you do not leave things at 777 unless
absolutely necessary (temp, user carts, and session
directories, for example, will probably need to be left as 777
because the web server must write to them, but your main
application filename.cgi should probably not be left as
777...actually, you may want to make it 755)!
Also, in Teach Yourself CGI Programming with Perl, Eric
Herrmann writes "Most servers run CGI Scripts as user
NOBODY. A file that "you" can access is not necessarily
accessible by that user." Very true...beware. Something that
runs okay from the command line may not work from the
web. To avoid this, you might try telnetting to port 80 and
doing GET, becoming your own browser and getting more
info. Anyway, enough of that, I recommend looking at a
UNIX manual for a real explanation. It is not all that hard
actually.
Also, Matt Wright found this great list of links to the UNIX
MAN pages on the web at
Yahoo I recommend that
you take
some time to read these pages as permissions is the number
one reason that scripts don't work on your server right out of
the box.
Finally, in some cases, you most also change the permissions
of the root directory itself because the main scripts must write
to the same directory in which it is located. Make sure you go
up a directory and chmod the root directory of the script you
are trying to run.
Well, that's all folks. If you are comfortable with the debugging tools outlined here and you are ready to get your mindset in gear, then you should have no worries. Think of CGI debugging as fun. In fact, to get practice, try going to a CGI discussion
forum and helping people solve their problems. You will not only hone your own skills, but make the CGI community a happier group to be a part of. Good luck.
