An Introduction to Unix Permissions -- Part Two
Pages: 1, 2
Remember from last week that what a user can do with a file depends on both the file's permissions and the directory's permissions. Let's make a test directory in our home directory to store some test files:
cd mkdir testdir cd testdir touch testfile ls -latotal 2 drwxr-xr-x 2 genisis wheel 512 Aug 20 10:24 . drwxr-xr-x 14 genisis wheel 1024 Aug 20 10:23 .. -rw-r--r-- 1 genisis wheel 0 Aug 20 10:24 testfile
Note the interesting behaviour with the times. The parent directory was last modified when
testdir was created, as its name had to be added to the parent directory's list. (Remember from last week that a directory is simply a file containing a list of the directory's contents). Similarly, the
testdir directory was modified the same time that the
testfile was created, as it also had to be added to its directory list.
Now, I want you to
login as a different user (other than root). Looking at the permissions for the testdir directory, will that user be able to
cd into that directory, use the
ls command, read a file, change a file, create a file, or remove a file? As you try this exercise, remind yourself which permission is allowing or preventing that user from doing something in the
testdir directory. I'll
login as the user
exit login: bikoPassword:
Note the shortcut to return to
genisis' home directory. Looks like the execute permission for everyone on
cd into it.
ls -latotal 2 drwxr-xr-x 2 genisis wheel 512 Aug 20 10:24 . drwxr-xr-x 14 genisis wheel 1024 Aug 20 10:23 .. -rw-r--r-- 1 genisis wheel 0 Aug 20 10:24 testfile
Looks like the read permission for everyone on the
testdir directory allowed
biko to list its contents.
Looks like the read for everyone on the
testfile allowed its contents to be read. Even though the file was empty,
biko did not receive an error message.
touch myfiletouch: myfile: Permission denied
biko doesn't have write permission to this directory, so he won't be creating any files in it.
rm testfileoverride rw-r--r-- genisis/wheel for testfile?
yrm: testfile: Permission denied
Again, lack of write permission will prevent
biko from removing files from this directory.
mv testfile ~mv: rename testfile to /home/biko/testfile: Permission denied
This is a move operation;
biko would need write permission on the
testdir directory for this to work.
cp testfile ~
This copy operation was successful as
biko does have write permission on his home directory.
ls -la >> testfiletestfile: Permission denied.
Here I was trying to append the results of
ls -la to the end of the testfile. If
biko had write permission, he would be able to do this.
Now, how would we give
biko permission to create files in this directory but not delete any files which were created by
genisis? See if you can come up with a solution in both absolute and symbolic mode before testing your theory. Note, you have a choice of giving permission to the primary group, to everyone else, or to both. You'll have to log in as the original user who made the testdir directory in order to change its
permissions. And don't forget to change your directory's sticky bit.
Now is a good time to mention groups, as group membership is an important consideration when setting permissions. To see what groups you belong to, simply type:
To see what groups anyone else belongs to, add their login name to the end of the groups command like so:
Here I have two users who don't live in the same group. If I wanted them
to share a directory, I could set permissions on everyone, but this would
also give permissions to everyone else. Alternately, I could make them
members of the same group and set permissions for the group. With this
method, I may also have to change the primary group of the file using the
chown command. Let's create a group called
projects and add these two users to it. Become root, as only root can make new users or groups. We'll use the
pw command to create the group; first, we'll type
pw to get the syntax:
usage:pw [user|group|lock|unlock] [add|del|mod|show|next] [help|switches/values]
Then we'll add a group with the fairly straightforward syntax:
pw group add projects
Then we'll verify that it worked like so:
grep projects /etc/groupprojects:*:1006:
Our new group is showing up in the
/etc/group database with a group ID of
1006. Now, I'll want to add the users
biko to the group like so:
pw groupmod projects -M genisis,biko grep projects /etc/groupprojects:*:1006:genisis,biko
Everything looks good; one last test to verify:
groups genisiswheel projects
groups bikobiko projects
Note that you can belong to more than one group at a time in FreeBSD. Now
all we have to do is change the primary group of the
testdir directory so we can give permissions to just
biko. The user
genisis can do this, as she owns the directory, so we'll exit out of the root account and log back in as
cd chown :projects testdir
Note that the
chown command requires a full colon (
:) to indicate you want to change the primary group, not the owner of the file or directory.
Now, let's see if the change was successful:
ls -la testdirtotal 2 drwxr-xr-x 2 genisis projects 512 Aug 20 10:24 . drwxr-xr-x 14 genisis wheel 1024 Aug 20 11:45 .. -rw-r--r-- 1 genisis wheel 0 Aug 20 10:24 testfile
We can now set permissions for the projects group, and it will only affect
I'd like to end this article with some common permissions to set on directories that you create.
If you create a directory that will contain private data that you only
want yourself to access, set its permissions to
700. Users will be able to see the directory, but they won't be able to
cd into it, list its contents, or modify any of the files in it. Keep in mind that root is not subject to permissions, so nothing is really hidden from the root account.
If you wish to have a directory inaccessible to a group of users, set its
705. This works, as FreeBSD stops reading permissions when it finds a match. This means that FreeBSD first checks to see if you are the owner of the file; if you are, you are subject to the owner's permissions. If you are not the owner, it then checks to see if you belong to the primary group of the file; if you do, you are subject to that
group's permissions. If you don't, you are subject to the permissions of
If you want a group to be able to write files, but only delete their own
files, set the directory's permissions to
Practice reading directory listings to determine what you can and can't do
with a file. When you see a listing, think which
chmod command would have set that permission. Before you know it, you'll be able to look at a
listing and know how to change its permissions so your users can do what
you want them to do.
Next week, we'll do some customizing of the user environment by learning how to change our shell prompt.
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.