Beginners Guide to Linux File System Permissions

Linux Filesystem Permissions

File permissions control access to files. The Linux file permissions system is simple but flexible, which makes it easy to understand and apply, yet still able to handle most normal permission cases easily.

Files have three categories of user to which permissions apply. The file is owned by a user, normally the one who created the file. The file is also owned by a single group, usually the primary group of the user who created the file, but this can be changed. Different permissions can be set for the owning user, the owning group, and for all other users on the system that are not the user or a member of the owning group.

The most specific permissions take precedence. User permissions override group permissions, which override other permissions. Three categories of permissions apply: read, write, and execute. The following table explains how these permissions affect access to files and directories.

r (read) Contents of the file can be read. Contents of the directory (the file names) can be listed.
w (write) Contents of the file can be changed. Any file in the directory can be created or deleted.
x (execute) Files can be executed as commands. Contents of the directory can be accessed. (You can change into the directory, read information about its files, and access its files if the files’ permissions allow it.)

Note that users normally have both read and execute permissions on read-only directories so that they can list the directory and have full read-only access to its contents. If a user only has read access on a directory, the names of the files in it can be listed, but no other information, including permissions or time stamps, are available, nor can they be accessed. If a user only has execute access on a directory, they cannot list the names of the files in the directory, but if they already know the name of a file that they have permission to read, then they can access the contents of that file by explicitly specifying the file name.

A file may be removed by anyone who has write permission to the directory in which the file resides, regardless of the ownership or permissions on the file itself. This can be overridden with a special permission, the sticky bit, discussed later in this chapter.

File Permissions Linux V/s Windows

- Linux file permissions work differently than the permissions system used by the NTFS file system for Microsoft Windows. On Linux, permissions apply only to the file or directory on which they are set. That is, permissions on a directory are not inherited automatically by the subdirectories and files within it. However, permissions on a directory can block access to the contents of the directory depending on how restrictive they are.

- The read permission on a directory in Linux is roughly equivalent to List folder contents in Windows.

- The write permission on a directory in Linux is equivalent to Modify in Windows; it implies the ability to delete files and subdirectories. In Linux, if write and the sticky bit are both set on a directory, then only the user that owns a file or subdirectory in the directory may delete it, which is close to the behavior of the Windows Write permission.

- The root user on Linux has the equivalent of the Windows Full Control permission on all files. However, root may still have access restricted by the system’s SELinux policy and the security context of the process and files in question. SELinux will be discussed in a later course.

Viewing file and directory permissions and ownership

The -l option of the ls command shows more detailed information about file permissions and ownership:

[user@host~]$ ls -l test
-rw-rw-r--. 1 geek geek 0 Feb  8 17:36 test

You can use the -d option to to show detailed information about a directory itself, and not its contents.

[user@host ~]$ ls -ld /home
drwxr-xr-x. 5 root root 4096 Jan 31 22:00 /home

The first character of the long listing is the file type. You interpret it like this:

  • - is a regular file.
  • d is a directory.
  • l is a soft link.
  • Other characters represent hardware devices (b and c) or other special-purpose files (p and s).

The next nine characters are the file permissions. These are in three sets of three characters: permissions that apply to the user that owns the file, the group that owns the file, and all other users. If the set shows rwx, that category has all three permissions, read, write, and execute. If a letter has been replaced by -, then that category does not have that permission.

After the link count, the first name specifies the user that owns the file, and the second name the group that owns the file. So in the example above, the permissions for user geek are specified by the first set of three characters. User geek has read and write on test, but not execute. Group geek is specified by the second set of three characters: it also has read and write on test, but not execute. Any other user’s permissions are specified by the third set of three characters: they only have read permission on test.

The most specific set of permissions apply. So if user geek has different permissions than group geek, and user geek is also a member of that group, then the user permissions will be the ones that apply.

Examples of Permission Effects

The following examples will help illustrate how file permissions interact. For these examples, we have four users with the following group memberships:

operator1 operator1, consultant1
database1 database1, consultant1
database2 database2, operator2
contractor1 contractor1, operator2

Those users will be working with files in the dir directory. This is a long listing of the files in that directory:

[database1@host dir]$ ls -la
total 24
drwxrwxr-x.  2 database1 consultant1   4096 Apr  4 10:23 .
drwxr-xr-x. 10 root      root          4096 Apr  1 17:34 ..
-rw-rw-r--.  1 operator1 operator1     1024 Apr  4 11:02 lfile1
-rw-r--rw-.  1 operator1 consultant1   3144 Apr  4 11:02 lfile2
-rw-rw-r--.  1 database1 consultant1  10234 Apr  4 10:14 rfile1
-rw-r-----.  1 database1 consultant1   2048 Apr  4 10:18 rfile2

The -a option shows the permissions of hidden files, including the special files used to represent the directory and its parent. In this example, . reflects the permissions of dir itself, and .. the permissions of its parent directory.

What are the permissions of rfile1? The user that owns the file (database1) has read and write but not execute. The group that owns the file (consultant1) has read and write but not execute. All other users have read but not write or execute.

The following table explores some of the effects of this set of permissions for these users:

The user operator1 can change the contents of rfile1. User operator1 is a member of the consultant1 group, and that group has both read and write permissions on rfile1.
The user database1 can view and modify the contents of rfile2. User database1 owns the file and has both read and write access to rfile2.
The user operator1 can view but not modify the contents of rfile2 (without deleting it and recreating it). User operator1 is a member of the consultant1 group, and that group only has read access to rfile2.
The users database2 and contractor1 do not have any access to the contents of rfile2. other permissions apply to users database2 and contractor1, and those permissions do not include read or write permission.
operator1 is the only user who can change the contents of lfile1 (without deleting it and recreating it). User and group operator1 have write permission on the file, other users do not. But the only member of group operator1 is user operator1.
The user database2 can change the contents of lfile2. User database2 is not the user that owns the file and is not in group consultant1, so other permissions apply. Those grant write permission.
The user database1 can view the contents of lfile2, but cannot modify the contents of lfile2 (without deleting it and recreating it). User database1 is a member of the group consultant1, and that group only has read permissions on lfile2. Even though other has write permission, the group permissions take precedence.
The user database1 can delete lfile1 and lfile2. User database1 has write permissions on the directory containing both files (shown by .), and therefore can delete any file in that directory. This is true even if database1 does not have write permission on the file itself.