Unix file permissions


This article provides an introduction to traditional UNIX permissions available on a GNU/Linux machine and explains the intricacies of setting permissions properly using advanced Access Control Lists (ACL's).


On a shared web hosting GNU/Linux based server there are many unrelated user accounts. Under this type of environment, it is important to set permissions properly in order to prevent users from accidentally or maliciously interfering/viewing the data of other users, whilst still allowing services like apache access to the data that they need.

The test system used for this article is running Red Hat Enterprise Linux ES 3 on x86.


There are 3 permissions available in Linux:

On a file, the permissions pretty much do what they say:

On a directory, the interpretation of the permissions are slightly different:

Permission names can also be abbreviated: 'r' for Read, 'w' for Write, and 'x' for eXecute. Thus a permission of rwx means 'Read, Write, and Execute'.

Permissions are also often represented numerically in octal (base 8):

A set of permissions can then be represented by simply adding up the numbers. For example the octal permission value of 05 means read and execute access.

Traditional Linux ACL's

Each object (files, directories, etc) in Linux has an user identification (UID) and a group identification (GID). For example:

[pawn@juggernaut pawn]$ touch new_file
[pawn@juggernaut pawn]$ ls -ln new_file
-rw----r--    1 10000    100             0 Mar 12 12:21 new_file
[pawn@juggernaut pawn]$ ls -l new_file
-rw----r--    1 pawn     users           0 Mar 12 12:21 new_file

In the above example the file new_file has a numeric UID of 10000. From the password database, this corresponds to the user name of pawn as shown in the third command. The file has a numeric GID of 100. This corresponds to the group name users.

Access to objects (files, directories, etc) in Linux is controlled by 3 sets of permissions. These are:

As you may have guessed from the previous example the permissions of the file new_file are listed in the first column of the ls -l output.

Like the individual permissions, the 3 sets of permissions can also be represented numerically in octal. Using the example file above, the permissions would be represented as 604.

Permissions can be altered via the command line utility chmod. Run man chmod from the command line for details. The manual for the chmod utility also details some extra permission bits (setuid, setgid, sticky) which will not be covered in this article.

Order of permission checking

When deciding whether a process can access an object the order of the checks is:

Protecting shared hosting users

In our shared hosting scenario as outlined in the introduction, we would like the Apache httpd server (running as user apache) to be able to access the public files of our user pawn. We don't want other users on the system to be able the files of the user pawn though. So how can we do this?

Why, through the power of negative ACLs! From the permission checking order section above, we see that if a user is a member of the group that the file GID is set to, then the permission that will apply to them is whatever is set for the group. The "other" permission set will never be checked!

This means that in our example, another user who is a member of the group "users" will NOT be able to access the file, whilst the user "apache" will be able to access the file due to the "others" permission set.

Thus to ensure that users cannot access each others files:

The umask lists the permissions which get cleared out on new file creation.

Wiki: dedicated/unix_file_permissions (last edited 2010-12-07 12:05:46 by BarneyDesmond)