Permissions - Permissions - Permissions
Click
Here for additional information
When Technical Support starts looking at a script that is not working,
the first thing checked is the permissions on the file. Understanding how
permissions work can save you a lot of time in debugging 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'. (Who's on first??? ) If you have FrontPage
extensions, things are a little different (see below).
If your script need's to write to a file on the system, you must set special
permissions to that file or directory. Any script that keeps a log (such as
counters) or alters HTML pages (such as wwwboard and guestbook) or save orders (such as
perlshop) must have permission to create and write to the files.
So, how to set permissions? First, a quick lesson on the UNIX
chmod command. (If you already know this, then skip
ahead.)
Every file and directory on the UNIX 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. (Yes, sometimes there are 4 numbers and sometimes 's' and 't' are
used. But those are unusual circumstances. If you knew that, you should have skipped ahead.)
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.
Some common settings:
Letters |
Numbers |
What happens |
rwxrwxrwx |
777 |
Readable, writable and executable by everyone |
rwxr-xr-x |
755 |
Readable and executable by everyone, writable by you |
rw-rw-rw |
666 |
Readable and writable by everyone |
rwx--x--x |
711 |
Everyone can use it but only you can read or change it. |
rw-r--r-- |
644 |
Everyone can read it but only you can change it |
Some not-so-common settings:
Letters |
Numbers |
What happens |
--------- |
000 |
No one can read, write or execute the file. The file can be deleted
according to the permissions of the parent directory |
--x--x--x |
111 |
The file can be executed, but no one can ever change it or read it |
rwx-w--w- |
744 |
Everyone can write to the file, but only you can read it or execute it.
(It's not a good idea to execute a file that someone else can change.) |
Use the UNIX chmod command to reset the permissions. Run 'chmod ??? filename'
from the te.netmand line. Or, most FTP programs will allow you to right
click on the filename and select 'chmod'.
Now, back to 'nobody'. Although no one is
'nobody', 'nobody' is somebody and so is included with 'everyone'. (What's on
second???) 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.
Is there an easier way? Maybe. Our
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 ... well ... optional.
The option, referred to as SUEXEC, allows us 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. Yes, it's easier, but...
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'. Oh, yeah, you skipped that part.) 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.)
|