The Basics of Linux Filesystem Permissions

For sysadmins, having a solid grasp of Linux filesystem permissions is essential, not only for understanding how files are accessed and controlled, but also in maintaining security of the data on a systems. This article assumes a basic understanding of Linux or other POSIX complaint OS and is an introduction in a multi-part series on how linux filesystem permissions work.

Owner, Group and Other

Every file in Linux has three different classes of access:

1. Access for the Owner
2. Access for a Group
3. Access for everyone else (Other)

A file is always owned by one user, typically the user that created it. The owner has the most control over the file and is able to do almost anything to it. Even if the owner makes it so a file is read-only, the owner still retains the ability to change the permissions back.

Group access to a file allows members of a particular group accsss to a file. Anyone who is a member of the group is able to perform whatever action the permissions allow on that file. The owner is typically part of a file’s group, but isn’t required to be. A group member that is not the owner of a file is not able to change the permissions set on file.

If a user is not the owner or not a member of the file’s group then that user’s level of access is specified by the other permissions.

The Superuser

The account root is a special user, called the super user, that has the ability to override any permissions set on any file and is generally allowed to do whatever it wants.

File Types and the Mode String

You can see file permissions by using the ls -l command:

pi@corinth:~ $ ls -l
total 8
drwxr-xr-x 2 pi pi 4096 Jan 31 21:13 blog
-rw-r--r-- 1 pi pi   27 Jan 31 21:14 README.md

The block of letters and dashes before the first space on each line specifies the type of file and its permissions.

The first character is the file type and has the following possible values:

The next nine characters are called the mode string and define the permissions. Each set of three characters define the permissions for the owner, group and others respectively. Each set of three characters can have the following values:

Permissions on Symlinks

You may notice that symbolic links, that is, files of type ’l’, have all the permission bits set on. This is because symlinks themselves are only references to another file and do not, in and of themselves, have permissions.

Let’s look at these in more detail.

Read and Write

These do exactly what one would think. They control read and write access to a file. In the case of directories, the read permission allows listing the contents of the directory and the write permission allows creating new files within the directory.

Execute

The execute permission allows a file to be executed. This includes actual binary executables and script files. A program file cannot run if the execute bit is not set on it.

For directories the execute permission allows the directory to be traversed.
That is, it allows the user to change directories into the directory and manipulate the contents of a directory. Removing the execute permission from a directory is generally not done although there are cases when it is desireable to prevent users from even entering a directory.

Sticky bit

Historically the sticky bit was used to save a program to the swap device so that it would load more quickly, but this has never been used on Linux. When the sticky bit is set on directories, however, it has a different meaning. On directories it is called the restricted deletion flag. When it is set on a directory, only the superuser, the directory’s owner, or the file’s owner can delete files within the directory. The t flag will only appear in the third position of the other set of permissions. Here’s an example:

pi@corinth:~ $ ls -l
total 8
drwxrwxrwt 2 pi pi 4096 Feb  1 21:31 blog
-rw-r--r-- 1 pi pi   27 Jan 31 21:14 README.md

Setuid and Setgid

The setuid and getgid bits have different meanings depending on if they are set on files or directories. When set on executable files, the file is executed with the privileges of the file owner (for setuid) or file group (setgid) or both if both bits are set. This is useful when a user needs to run a program with the effective privileges of another user. This is often the case with programs that must manipulate privileged files but still need to be run by regular users such as the passwd program. Setuid/Setgid can pose some serious security risks if used improerly. For example, if a user was able to execute a copy of bash that was setuid root then that use would effectively have superuser privileges on the system.

Script Files

Linux will ignore setuid/setgid on script files for security reaons.

On directories the setuid and setgid bits have a different meaning. Setuid is ignored on directories in Linux, but setgid causes any files or directories created in that directory to inherit the group of the directory and not the primary group of the user that created them. This is useful in directories where files need to be shared among a group of users.

Files moved into setgid Directories

Files that are moved into a setgid directory are not affected by the setgid bit as they are not created, but moved into the directory.