<P>Note:  This file has moved to <A HREF="/notablog">notablog</A>.</P>

     Most web servers are unix-flavored, which means that beyond the
file system stuff you may be used to, every file has a set of values
associated with it: user, group, and a set of nine "permission" flags.

     The user and group values actually interrelate with the nine
permission flags (see the example table below), so it takes a little
bit of work to describe them.   The permissions break down into three
subsets, user permissions, group permissions, and "other" permissions.
(To make it more complicated, often in conversation you see/hear the
term "world" used as a synonym for "other.")  For each subset, there
are three permissions:  read, write and execute.

     Read permission means quite simply permission to read the
contents of the file, i.e. to execute a system command and get
back the data contents of the file.

     Write permission means permission to modify the file - to
overwrite exisitng data or append new data.

     Execute permission means permission to ask the operating system
to treat the file as a list of commands to execute.  In a single-user
system with no security scheme to speak of (like ms-windows) this
wouldn't make any sense, but in a multi-user, somewhat secure system
like unix, execute permission determines whether other people can run
a file full of commands that you wrote.

     Now let's define user, group and other.

     User is the user who owns the file.

     Group is one of an arbitrarily defined list of groups to which
users in the system *may* belong.  A group is essentially a group
name, unqiue group ID, and list of users that belong to it.  Thus,
users can belong to multiple groups.  Each file has a single group
value.

     Other is everybody else, i.e. anybody who is NOT the user who
owns the file or a member of the same group the file belongs to.

     The nine permission flags break down into three types of
permission: read, write and execute.  As I said above, there are three
flags (read write execute), for three subsets (user, group and other).
If you enter the command "ls -l<enter>" you'll see a listing of each
in your current directory, for example: 

     -rwxrwxrwx    2 puff     puff         4096 Apr 23 21:47 test

     This file has all of the permission bits turned on:

           read  write  executable
     user     r      w      x
     group    r      w      x
     other    r      w      x

     If we turn off group write permisssion with "chmod g-w test" and
list it again:

     -rwxr-xrwx    2 puff     puff         4096 Apr 23 21:47 test

           read  write  executable
     user     r      w      x
     group    r             x
     other    r      w      x

     If we also turn off other write permisssion with "chmod o-w test"
and list it again:

     -rwxr-xr-x    2 puff     puff         4096 Apr 23 21:47 test

           read  write  executable
     user     r      w      x
     group    r             x
     other    r             x

     By the way, we could have just turned the both off at once, by
lumping together the "g" and "o" like so "chmod go-w test".  If you
used "+" instead of "-", chmod would set those permissions to on.
 

Gotchas

     Beyond the above details, there are some gotchas to be aware of:

Executable and Writable Files

     Normally when anybody runs an executable file, it runs "as" the
user who ran it.  It can do anything that user can do - so if you run
a file, it can delete all your files, or email them all to somebody
else, or anything you could do.  It's always wise to make sure what's
in what you're running before you run it.

     On the flip side, when somebody else runs your file, it can't
muck about with your files (unless you use special commands to make
that possible - called the setGUID bit, and VERY DANGEROUS for novices
to play with).  However, if you have a file writable by anybody else
but you, and executable at all (by yourself or by other users), you've
created a risky situation.  What if somebody came along and edited
some nasty commands into that file between the last time you read it
and when you run it?  When the file runs, it effectively has all the
access you'd have.

Directory Execute Permission

     In Unix, a directory is a file, with its own set of bits.  The
"ls" command executes the directory to list what files it contains.
So if you have a directory with the "execute" permission turned off,
you can't list it.  You also can't point your browser at it.  More of
a gotcha is, say you have a file inside of directory inside of a
directory inside of a directory, inside your htdocs directory:

     ...htdocs/foo/bar/baz/what.html

     If any of the directories in that set has the execute permission
turned off, you won't be able to get at it via the web.

Directory Write Permission

     You need write permsision to edit the contents of a directory -
that is, to rename or remove files.  The gotcha is that once you have
write permission in a directory, you can rename or remove *any* file,
even one that doesn't belong to you.


SetUID Bit, SetGID Bit 

     The SetUID bit is tricky and dangerous for novices to use.
Essentially, it reverses the normal situation I described above in
"Executable and Writable Files".  When anybody runs the file, it runs
as if *you* ran it.  This means that you need to be extra careful
about security on that file (a file that is both writable AND setUID
is a timebomb waiting to happen).  You also have to think very
carefully about the commands that *are* in the file, since somebody
could figure out a way to feed it the wrong arguments and cause
behavior you didn't anticipate.  This is a huge and tricky topic to
understand, and there's no way in hell I can go into it here with any
level of details.

     The setGID bit is like the setUID bit, only for groups - the file
runs as a member of that group, even if the user running it isn't a
member of that group.

Further Reading

A more thorough introduction to Unix permissions is at:

http://www.onlamp.com/pub/a/bsd/2000/09/06/FreeBSD_Basics.html