|
|
|
|
Whose
directory is this anyway? By
Joel Colvin © 1996 Colvin Training & Consulting A misunderstanding of file and directory permissions causes
one of the most common problems encountered on Unix systems.
We will be covering directory permissions, potential pitfalls, and their
little known solutions. Unix file and directory permissions, also called
Discretionary Access Control on SCO UNIX, initially appears quite simple with
it's three flags of read, write, and execute.
The permission flag’s effect on files is fairly straightforward,
however their effect on directories is different.
Lets look at each of them and how they should be used. r (read permission) Any user that has read permission can list the contents of
the directory as well as read any individual files that also have read
permission. Any files that are
executable in that directory can be executed since a user only needs to read a
file to have it executed. w (write permission) Write permission on a directory is the most worrisome.
If you have write permission on a directory then you can create, append,
and delete files in that directory. You
can also move and delete the directory. With
write permission at the directory level a user can even gain ownership of any
file in that directory that can be read. For
example, because you can write in the directory, you can move the directory to a
new location, recreate the directory at its original location, and copy all the
files from the moved directory to the new one you created. Because you created the directory and its contents, you will
have ownership of both of them. Now
you can set the permissions any way you want before changing the ownership back. x (execute permission) The execute permission allows users to make the directory
their “current directory." This
allows users to actually cd into the
directory. Obviously, the write permission on directories leaves a
security hole. What if you have a
directory that has data files that you want to allow users to write to but you
don’t want them to be able to erase those files? For this we use the often-misunderstood sticky bit. The sticky
bit, when set on a directory, allows users to create and append to files in a
directory but only the owner of the directory or the owner of the file can
remove files. The sticky bit flag
is a t and appears in the place of
the final execute flag. For example: drwxrwxrwt joelc group
416 March 16 08:30 /u/mydir The above directory mydir allows any user on the system to
create and append to files in that directory but only the user joelc can remove
files from the directory. If you
are not logged in as joelc and the file you want to delete does not belong to
you, then you will not be able to delete it.
Remember that you should be able to delete any files you create because
you own them. You just won’t be
able to remove files that don’t belong to you even though you have write
permission at the directory level. If you want to add the sticky bit uses the chmod
command like this: chmod +t mydir Note: The sticky bit is obsolete. Its original purpose was to force an executable to be retained or stick in the swap space. This wastes swap space, but on busy systems this reduced the time to execute files such as /bin/sh, which is executed frequently. Finally, there is the SGID bit. The SGID or Set Group ID bit is usually used on executable
files. When set on a directory, the
SGID bit forces all files created in that directory to inherit the group id of
the directory instead of the group id of the user or process creating the file.
With this flag you can setup a directory that anyone can write to but
when a file is created it will have the group id that is designated for the
directory. Suppose the accounting
group needed to allow the sales group access to some of its files.
If accouting had a directory with the SGID bit set and its group was that
of sales (the ownership would still be acct) then they could place files in that
directory and they would automatically pickup the sales group id.
This allows the group sales access to files without the accounting group
being forced to use the chgrp command
every time they copied a file into that directory. If you want to add the SGID bit to a directory, again use the chmod command: chmod g+s mydir The result will be something like this: drwxr-sr-- acct sales 416 March 16 08:30 /u/mydir drwxr-Sr-- acct sales
32 March 16 08:35 /u/yourdir Notice the s in
place of the group execute permission flag.
A lower case s means that
execute permission also exists and an upper case S means that there is no execute permission. In this example, the acct user has full access to the
directory. They sales group has
read and execute permission on /u/mydir and read only permission on /u/yourdir.
Both directories will force a group id of sales to any files created
within. Anyone who is not acct or
belonging to the group sales has only read permission (i.e. they can execute
files in that directory but cannot make it their current directory.) Even if you
don’t use the sticky bit and the SGID bit you should be watchful for write
permission on directories. It is a
simple task to have the cron process provide a list of all directories that have
write permission. Something like: 0 4 * * 0 find /
-type d -perm -002 -print This contrab entry will run at 4:00 am on Sunday and find all directories that are “writable” by others (those who don’t own or belong to the group of the directory.) |