|The Second Superpower of Web Hosting|
We areHostWerks. A different approach to the web hosting business.
When Technical Support starts examining a script that is not working, the first thing that is checked are the permissions set on the file. Understanding how permissions work can save you a lot of time and help you debug your scripts.
When a script is accessed through the World Wide Web, it is normally run as a special user called 'nobody'. 'Nobody' has no rights to anyone's files and no one can login to the system as 'nobody'. If you have Microsoft Frontpage extensions, things are a little different (see below).
If your script needs to write to a file on the system, special permissions must be set on that file or directory. Any script that keeps a log (a page counter) or modifies the HTML code of a page (a guestbook) or save orders (Openshop) must have the proper permissions to create and write to the files it creates.
How are permissions set? You must use the chmod command. (If you are familiar with this, then move on.)
Every file and directory on our Cobalt server has it's own permission setting. This setting is normally represented by a group of letters (r, w & x) or a three digit number. Sometimes there are 4 numbers and sometimes 's' and 't' are used. But those are uncommon circumstances.
If you telnet to the server and list the files or if you look at the Directory Info through your FTP program, you will see the 'rwx' series in the listing. The first three letters refer to your user id. 'r' is for read, 'w' is for write and 'x' is for execute. (Although, sometimes you may want to think of 'x' as for use). If the first three characters are 'rw-', then you have read and write permissions to the file, but the file is not executable. The last three characters set permissions for the world. If the last three characters are 'r-x' then everybody can read and execute the file, but they cannot write to it. The middle three characters are used for permissions for the 'group'. For the most part, you should set these to the same setting as the world.
OK, what about the numbers?? Look at it this way: r = 4, w = 2 and x=1. For each group of 'rwx', add up the numbers to get a digit from 0 to 7.
Common Permissions Settings
Uncommon Permissions Settings
Use the chmod command to change the permissions. Run 'chmod ??? filename' from the telnet command line. Or, most FTP programs will allow you to right click on the filename and select 'chmod' to set the file permissions.
Now, back to 'nobody'. Although no one is 'nobody', 'nobody' is somebody and so is included with 'everyone'. What this means is the last three letters (or last digit) control WWW access. If you want a script to run, the script must be executable by 'nobody' (??1). If your script needs to write to a file, that file needs to be writable by 'nobody' (??4). If your script has to create a file, then the destination directory must be writable by 'nobody' (??4). If your HTML page doesn't show up, make sure 'nobody' can read it (??4 or ??5).
So what about my files? There are no set rules, but there are some suggestions. If the file is to be executed, use 755. If the file is to be written to, use 666. If the directory is to have new files created in it, use 666.
An Easier Way? Maybe. The server software has an option to set the user ID running the script. Frontpage sites require this option to be enabled. For other sites it is optional. The option, referred to as SUEXEC, allows HostWerks to set your site so that all access through WWW to your site is done as your user. You don't have to set the file as writable by everyone since your user ID has access to your files. You don't have to open your directories for the entire world to read since you can read your own directories.
Your user ID can delete your files. Well, that's OK if that's what you want. But you don't want someone creating a script that deletes your files when it runs as your user ID. So, SUEXEC runs several checks to be sure no one (and that includes 'nobody') can alter the file or directory that it is about to execute. Scripts run under SUEXEC (and consequently under Frontpage) cannot have the 'write' permission set for anyone but the owner. As a general rule (with many exceptions), files in a site with SUEXEC enabled should have permissions set to 755.
If you skipped ahead earlier, you may be asking: If the script is running as my user, why can't I set permissions to 700 so that only my user ID can use the file? Good question, but this gets deep(er). SUEXEC runs through 20 steps before changing to your user ID. Prior to that it is still operating as 'nobody'. If permissions on the directory containing the file are 700, 'nobody' can't read the directory to run the checks on the file ownership. The directory permissions must be at least 711. Remember, 'x' sometimes means 'use'. If you want the most restrictive setting on your files, you can set the directory to 711 and the scripts to 700. Output files can be set to 600.
If you want us to turn on SUEXEC for your site, just let us know. Remember, if you get an "Internal Server Error", start with file permissions. Then try running it from the command line.