When I was first learning Unix, it seemed that everything I tried to do resulted in the very irritating "Permission denied" message. I also quickly learned that if root starts messing with permissions before root knows what he is doing, all the neat utilities that come with Unix stop working.
Today's article is the first of two articles on permissions. In Part 1, I want to concentrate on recognizing file permissions and what they allow and don't allow you to do. Next week, we'll move on to actually changing default permissions and what to be careful of when you do so.
Unix uses three base permissions: read (r), write (w), and execute (x). To
view the permissions of the root directory on your FreeBSD system, use the
ls command with the l (show long listing) and a (show all files) switches
like so:
ls -la /
total 6087 drwxr-xr-x 16 root wheel 512 Aug 9 11:36 . drwxr-xr-x 16 root wheel 512 Aug 9 11:36 .. -rw-r--r-- 1 root wheel 658 Jul 26 23:14 .cshrc -rw-r--r-- 2 root wheel 251 Jul 26 23:14 .profile -r--r--r-- 1 root wheel 4735 Jul 26 23:14 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Aug 9 07:45 bin drwxr-xr-x 3 root wheel 512 Aug 8 17:14 boot drwxr-xr-x 2 root wheel 512 Aug 8 13:03 cdrom lrwxr-xr-x 1 root wheel 11 Aug 8 17:14 compat -> /usr/compat drwxr-xr-x 3 root wheel 12800 Aug 13 10:03 dev drwxr-xr-x 15 root wheel 2048 Aug 12 19:21 etc lrwxrwxrwx 1 root wheel 9 Aug 8 17:15 home -> /usr/home -r-xr-xr-x 1 root wheel 3087410 Jul 27 00:44 kernel -r-xr-xr-x 1 root wheel 3087410 Jul 27 00:44 kernel.GENERIC drwxr-xr-x 2 root wheel 512 Jul 26 23:00 mnt drwxr-xr-x 2 root wheel 2560 Aug 8 13:45 modules dr-xr-xr-x 1 root wheel 512 Aug 15 10:11 proc drwxr-xr-x 3 root wheel 512 Aug 14 10:21 root drwxr-xr-x 2 root wheel 2048 Aug 9 07:45 sbin drwxr-xr-x 4 root wheel 1024 Aug 8 13:03 stand lrwxrwxrwx 1 root wheel 11 Aug 8 17:06 sys -> usr/src/sys drwxrwxrwt 3 root wheel 512 Aug 15 09:24 tmp drwxr-xr-x 18 root wheel 512 Jul 27 01:09 usr drwxr-xr-x 18 root wheel 512 Jul 27 01:05 var
Let's pick apart this output. This long listing starts with:
total 6087
which is the number of 512-byte blocks used by the files within this directory. You only get this information if you do a long listing on a directory; to see the difference, do a long listing on a file, like so:
ls -l /.cshrc
-rw-r--r-- 1 root wheel 658 Jul 26 23:14 /.cshrc
After the total block information is a listing of all files in the
specified directory. To Unix, everything is a file; this means that data
files, directories, device entries, and links are all considered to be
files. The very first letter in a file's ls -la listing states what type of file it is. For example:
drwxr-xr-x 2 root wheel 1024 Aug 9 07:45 bin
bin is a directory as its listing begins with the letter d.
-rw-r--r-- 1 root wheel 658 Jul 26 23:14 .cshrc
.cshrc is a regular file as its listing begins with the character -.
lrwxrwxrwx 1 root wheel 9 Aug 8 17:15 home -> /usr/home
home is a symbolic link as its listing begins with the letter l. You'll also note that symbolic links use a -> to indicate the files that are linked.
The next nine characters represent the file's permissions. Permissions are
always listed in the order of read, write, and execute. If the letter
is listed, the permission is granted; if there is a - instead of the letter, that permission is denied. The permissions are repeated three
times to represent owner, primary group, and everyone else. In the
following listing:
-rw-r--r-- 1 root wheel 658 Jul 26 23:14 .cshrc
As before, .cshrc is a regular file -- its listing begins with a -. The owner of the file (root) has read and write permissions, but not the execute permission. Anyone in the primary group (wheel) has read permission to this file, but not write or execute permission. Everyone else has read permission, but not write or execute permission.
Note that the owner of the file is listed after the permissions; the primary group of the file is listed after the owner. This is followed by the size of the file in bytes, the date and time the file was last modified, and finally the name of the file.
What a person can actually do with a file depends on both the file's
permissions and the permissions of the directory the file lives in. Let's
look at the meanings of r, w, and x for regular files and directories, and then see if we can predict what a regular user can do with a file. Note that I said regular user; the root user is not subject to permissions -- one of the many reasons not to be root any longer than absolutely necessary.
If read (r) is set on a file, permission is given to view (not change) the contents of the file using an editor or a utility such as cat or more. If read is set on a directory, permission is given to list the contents (or files and subdirectories) within the directory using the ls command.
If write (w) is set on a file, permission is given to change the contents of the file using an editor or a redirector. If write is set on a directory, permission is given to change the contents of the directory; meaning you can create, move, or delete files within the directory.
If execute (x) is set on a file, it can be run as a program or a shell script. If execute is set on a directory, permission is given to cd into that directory.
|
In order to determine what a regular user can do to the /.cshrc file, we'll need to look at the permissions for both the .cshrc file and the / directory. I've snipped the output of ls -la to just give the two entries we're interested in:
ls -la /
drwxr-xr-x 16 root wheel 512 Aug 9 11:36 . -rw-r--r-- 1 root wheel 658 Jul 26 23:14 .cshrc
Note that "." represents the current directory. Root is a strange directory as it is the "root" of your system. Normally ".." represents the parent directory, or previous directory; since root is the beginning, both "." and ".." represent root, so their listings are identical.
So, what should a regular user be able to do with this file? They have rx permissions to the directory and r to the file. Looks like they'll be able to open up the file in an editor, but not make any changes to it. Will they be able to copy, move, or delete the file? Let's try and see.
If I open up the file in my favorite editor, I can read it fine, but I can't save any changes I make to it. So far, so good. Now I'll try:
cd /
cp .cshrc mycopy
cp: mycopy: Permission denied
mv .cshrc mycopy
mv: rename .cshrc to mycopy: Permission denied
rm .cshrcoverride rw-r--r-- root/wheel for .cshrc?yrm: .cshrc: Permission denied
As we expected, we could cd into the directory, but we couldn't copy, move, or remove the file within that directory, even though we were teased
a bit during the remove operation.
What will happen if we try to copy or move this file to another directory, say our home directory? Let's first look at the permissions on our home directory:
ls -la ~
drwxr-xr-x 12 genisis wheel 1024 Aug 15 11:34 .
Note that "~" is an abbreviation for your home directory; this saves a lot of typing. Now let's retry our commands:
cd /
cp .cshrc ~/myfile
mv .cshrc ~/myfile
mv: rename .cshrc to /home/genisis/myfile: Permission denied
Note that I didn't get an error message when I copied the file to my home directory; this means the command was successful. However, I wasn't able to move that same file into my home directory. This strange behavior makes sense if you understand what actually happens when you move and copy files.
Remember that everything is a file to Unix. Regular files contain data, such as text. A directory is really just a file which contains a list of the other files that live within the directory. In order to move a file, you have to remove the file from this list. If you don't have write permission to the directory, you can't change the list, so you won't be able to move the file.
In order to copy a file, you have to add the name of the new file to the
list of the directory you want to copy the file to. When we tried to copy
the .cshrc file within the / directory, we didn't have write permission to the / directory, so we couldn't copy the file. However, when we tried to copy .cshrc to our home directory, we had write permission to our home directory, so the copy was successful.
Unix also understands three specialty permissions that allow us to
fine-tune the default permissions. The first specialty permission is called
the SUID, or set user id bit. If you do a long listing, and see either an
s or an S instead of an x in the owner section of the permissions, this bit has been set.
The SUID bit allows a user to temporarily gain root access, usually in
order to run a program. For example, only the root account is allowed to
change the password information contained in the password database; however,
any user can use the passwd utility to change their password. Let's do a
long listing on the passwd command to see why:
whereis -b passwd
passwd: /usr/bin/passwd
ls -l /usr/bin/passwd
-r-sr-xr-x 2 root wheel 26260 Jul 26 23:12 /usr/bin/passwd
^
Because the SUID bit has been set on the passwd utility, it will become root in order to modify the password database, allowing the user to change their password.
If the SUID bit appears as an s, the file's owner also has execute permission to the file; if it appears as an S, the file's owner does not have execute permission.
The second specialty permission is the SGID, or set group id bit. It is
similar to the SUID bit, except it can temporarily change group
membership, usually to execute a program. The SGID bit is set if an s or an S appears in the group section of permissions. An example of a file with the SGID bit set is netstat:
ls -l /usr/bin/netstat
-r-xr-sr-x 1 root kmem 84448 Jul 26 23:12 /usr/bin/netstat
^
Since netstat's SGID bit is set with an s instead of an S, execute permission has also been set.
The third specialty permission is the directory sticky bit. This bit is essential if you have a directory that is used by more than one user. Remember the permissions for your home directory?
ls -la ~
drwxr-xr-x 12 genisis wheel 1024 Aug 15 11:34 .
The owner has full access to the directory, but all other users, including members of the owner's primary group, only have rx. Only the owner will be able to create and delete files from his home directory, which is a good thing.
However, these permissions aren't suitable for a shared directory where many users have to be able to create, modify, and possibly remove files from the directory. If you create a directory and give either a group or everyone write access to the directory, users will be able to create and modify files within the directory.
Unfortunately, write access to a directory also means that users can delete any file within the directory, even if they don't own the file. This is not nice, especially considering that once a file is deleted in Unix, it is gone forever.
This is where the directory sticky bit comes in. This bit is set if a t or a T appears instead of an x in the everyone section of permissions like
so:
drwxrwxrwt
When the directory sticky bit is set, users will still be able to create and modify files within the directory, but they will only be able to delete files which they themselves created.
All permissions on your FreeBSD system will be a combination of these base
and specialty permissions. Next week we'll use the chmod command in both absolute and symbolic mode to change the permissions on the files and
directories that you create.
Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.
Read more FreeBSD Basics columns.
Discuss this article in the Operating Systems Forum.
Return to the BSD DevCenter.
Copyright © 2007 O'Reilly Media, Inc.