File Permission FAQ

Introduction

In UNIX (as in some other operating systems or workstation environments) files have some sort of access controls that can restrict a user or a group of users.

Why would we want to do this? Sometimes we want to be able to let certain groups read some files (say like webpages for a webserver) and other times we don't want people to read files (say like personal correspondence).

In the Unix operating system (which includes Linux and Solaris machines), we can change the "permissions" or the "mode" of a file with the chmod (which is short for "change mode"). There are three modes that we can set: read, write, and execute. For files, this means that one can allow whether a user can read a file, whether they can write to (or modify) the file, or whether they can execute the file (like a program or a text file with a list of commands to run).

We can set any set of these permissions on a file at the same time. This makes it useful for when we are editing a file--we can both read from and write to the file.

In Unix, we can set these file modes for different classes of users: the user who owns the file, the group of whom the user is a part, and all others. For web files, the permissions that effect who can read your web pages are the "all others" class of users

Using the chmod command

To modify the mode of a file, the chmod command has a mneumonic mode, which is somewhat easier than the octal mode (to learn more about the octal mode, read the man page on chmod by using the command man chmod).

You can specify each of the three classes of permissions with the first letter of the name of the group:

You can specify whether you want to add a permission, set a permission, or revoke a permission with the following characters:

You then specify the read, write, and execute permissions with the same letters that you see in a long listing:

In an ls -l listing, if you were to see this


-rw-rw-r--    1 pakenned     programmers      1249 May 23 07:04 index.html

This output shows that the file is owned by user pakenned in group programmers. The file is readable and writeable by the user (pakenned) and the group (programmers). All others may only read this file.

If we wanted to make it so that the user couldn't write to the file (i.e. accidentally change it), the group members couldn't write to the file, and no change for all others, we would use the command:

In an ls -l listing, if you were to see this


$ chmod ug-w index.html
$ ls -l index.html
-r--r--r--    1 pakenned     programmers      1249 May 23 07:04 index.html

Frequently Asked Questions

I want to run this script, but it doesn't run...
You'll need to add the appropriate execute permission.
I can't see my web files! Help!
Make sure that there is at least execute permission set for the directory and that the file has the read permission set. Note that all directories leading up to this directory will need to have at least the execute permission set for the class "other". These permissions need to be for the class of "other" users, since the webserver typically runs as "nobody".
I can't list my directory of web files in my browser. How do I do this?
You'll need to set both read and execute on the directory. You'll probably want to read the previous question's response as well.
I'm in the XXX group, but can't change permissions - why not?
Only the owner of a file can change permissions, even if others have group write access. The proper fix is to ensure that project members set permissions properly when creating files. If people don't change the default umask, new fils will be created properly. If people unpack from tar files, then they'll likely need to change permissions. It is possible to do the rename-and-copy trick as a workaround:
mv file file.tmp
cp file.tmp file
rm file.tmp
Now you'll own the file. This only works if you have write permission to the directory where the file is stored and the sticky bit is not set (as is the case with some of the older group setups).
Is there a way to make sure that all new files created in a given directory will be setup with group read/write permissions?
By combining permissions and group ownership of the directory with the use of something called a sticky bit, it's possible to make sure that the desired group owns the file by default. The following is a step-by-step that I used to set the directory registration1 to be modifiable by group techga:

$ groups
$ chgrp  techga  registration1
$ chmod  2775  registration1
$ ls -l
drwxrwsr-x    2 mwolske  techga       4096 Jan 10 08:56 registration1

The first step lists the groups to which I belong, allowing me to confirm I was a member of techga. The second changed the group ownership of the subdirectory registration1 to techga (this subdirectory was immediately below the directory I was in). The third step made the directory read/write/execute for me as owner and for techga as group owner, and read/execute for everyone else. The initial '2' sets the sticky bit for group ownership, so any new files created in that directory will now be owned by group techga. The final step lists the settings; note in the output that the initial 'd' signifies that this is a directory, the first set of 'rwx' signifies read/write/execute for owner, the 'rws' for group signifies read/write/execute/sticky for group, and the 'r-x' signifies read/execute for other.

If an individual would like to assure that every file or directory they create has a consistent ownership setting by default, they would set their umask at login. The umask is the inverse of the permissions that are desired. To create files or directories with all permissions set for owner and group, but no write access for others, the umask would be setup as follows:


$ umask 002

This can be added to a users .profile file in their home directory to take effect automatically each time they login.
How do I find out more?
For more information regarding file modes and directory permissions, the interested reader can refer to the Unix man pages (type man chmod at the Unix shell prompt).

Valid HTML 4.01!


isrl-support@isrl.uiuc.edu