Unix File Access Permissions

Unix File Access Permissions

This is a tutorial on controlling access to your files on a Unix system. This tutorial is meant to help researchers work together in groups following the CSE Research Account Policy.

The examples and exact command syntax shown are for the System V (Solaris 2) flavor of Unix. There are minor differences for BSD (SunOS 4), most of which are pointed out in the text.

The semantics of file sharing under Unix may at first blush seem a little absurd. The feeling may not go away. Unix was designed as an open system where by default everyone has at least read access to everything and further restrictions are an exception, not the rule.

File Access

There are three parts to file access: which, what, whom. Which filesystem objects can what be done to by whom?

Which filesystem objects...

There are two common types of filesystem object: files and directories. Files are created by writing into them and removed using the rm command. Directories are created using the mkdir command and removed using the rmdir command.

...can what be done to...

The three actions you can take with an object are called: read, write, and execute, abbreviated r, w, and x. Although this terminology is a little strained with some types of objects, I'll use it everywhere for consistency.

Where the term path is used in talking about directories, generally the full path is meant. This is the path all the way back to the root directory /, for example, /user/username/subdir/object. The section on links points out some difficulties in determining what the full path actually is.

Directory Permissions:

You must explicitly create a directory using the mkdir command. You need write and execute access to the directory in which the new directory is to be placed. For this and other directory operations, you need have only execute access to all the prior directories in the path.
You read a directory when you list the files in the directory. You need read and execute access to the directory in which the files you are listing reside. To list only a specific file, not the entire directory, you need only execute access to its directory.
You write a directory when you create or remove a file in the directory. You need write and execute access to the file's directory.
You remove a directory using the rmdir command. You do not need any access to the directory you are removing, only to its parent directory.
You execute a directory when you use the directory as part of a path name. You cannot do anything with a directory (except remove it) without having execute access to it.

File Permissions:

To create a file you need write and execute access to the directory where the file is to be placed.
To write or append to an existing file you need execute access to its directory and write access to the file.
To read a file you need execute access to its directory and read access to the file.
To remove a file you need write and execute access to its directory. You do not need access to the file.

...by whom?

The system knows about three classes of user: the owner, the group, and all others. You can assign the `rwx' access for each of these three classes independently. The mode field in the ls listing of a file is ten characters, one for object type, and three each for owner, group, and other.

The ls command with the options -Fal shows you most of the interesting information about filesystem objects. (Use ls -Fagl on BSD systems.) For example:

   drwxr-x--x  3 lees  prip      512 Nov 21 16:43 ./
drwxr-xr-x 12 root  root     1024 Nov 21 15:48 ../
drwxrwx---  2 lees  prip      512 Nov 21 14:13 Project/
-rw----r--  1 lees  manager   131 Nov 21 14:16 file
-rwx--x--x  1 lees  manager 32768 Nov 21 16:40 program*

Hard links should generally be avoided except within the same directory. A hard link cannot span filesystems. Directories sometimes migrate between filesystems without users being aware of the changes. This generally would cause the linked file to actually be duplicated. Then when you modify one copy of the file, the other copies (previously links) would not change.

A symbolic link is a special kind of file that contains as data a path to some object, which may be in another filesystem. A symbolic link can point to a directory. When you do an ls -l what you see is this path:

lrwxrwxrwx 1 lees prip 10 Oct 28 09:04 what -> over/there

The path in a symbolic link may point to an object that does not exist. This is not checked when you create the link, and nothing tells you when the object is moved, renamed, or removed. Ownership, group, and permissions are set on the object pointed to, not on the link.

When you cd through a symbolic link, things can be a little confusing. The pwd command works by doing repeated cd .. until it gets to the root directory `/'. So pwd shows the true full path, not the path through the symbolic link. If you don't realize you are going through a symbolic link, this can result in the `How did I get here?' syndrome. Look at your command history to figure out what you did.

Links And Projects

Symbolic links can be used to make directories that are actually located in a project directory appear to be in your home directory. This can make it easier for you to create makefiles and to work with the project files.

Project PI's need to watch that symbolic links are not used the other way around: to make files in individual accounts appear to be in the project directory. The PI has control only over those files that are actually in the project directory!

See Also

chmod(1), groups(1), id(1), ln(1), ls(1), newgrp(1), umask(1), and: Lisa Lees, `Unfamiliar File Objects', Sys Admin, Vol. 4, No. 4, Jul/Aug 1995, pp. 24-36.

Welcome

People

Research

Academics

Community

Events

Resources

Horizon Fund

Follow CSE