BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


An Introduction to Unix Permissions
Pages: 1, 2

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.

 





Sponsored by: