ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


FreeBSD Basics

An Introduction to Unix Permissions

09/06/2000

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 .cshrc
override rw-r--r--  root/wheel for .cshrc? y
rm: .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 © 2009 O'Reilly Media, Inc.