Linux Filesystem Permissions
File permissions control access to ﬁles. The Linux ﬁle permissions system is simple but ﬂexible, 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 ﬁle is owned by a user, normally the one who created the ﬁle. The ﬁle is also owned by a single group, usually the primary group of the user who created the ﬁle, 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 speciﬁc 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 ﬁles and directories.
|PERMISSION||EFFECT ON FILES||EFFECT ON 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 ﬁles 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 ﬁles in the directory, but if they already know the name of a ﬁle that they have permission to read, then they can access the contents of that ﬁle by explicitly specifying the ﬁle name.
A ﬁle may be removed by anyone who has write permission to the directory in which the ﬁle resides, regardless of the ownership or permissions on the ﬁle itself. This can be overridden with a special permission, the sticky bit, discussed later in this chapter.
File Permissions Linux V/s Windows
– Linux ﬁle permissions work differently than the permissions system used by the NTFS ﬁle system for Microsoft Windows. On Linux, permissions apply only to the ﬁle or directory on which they are set. That is, permissions on a directory are not inherited automatically by the subdirectories and ﬁles 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 ﬁles and subdirectories. In Linux, if write and the sticky bit are both set on a directory, then only the user that owns a ﬁle 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 ﬁles. However, root may still have access restricted by the system’s SELinux policy and the security context of the process and ﬁles 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 ﬁle 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 ﬁrst character of the long listing is the ﬁle type. You interpret it like this:
- – is a regular ﬁle.
- d is a directory.
- l is a soft link.
- Other characters represent hardware devices (b and c) or other special-purpose ﬁles (p and s).
The next nine characters are the ﬁle permissions. These are in three sets of three characters: permissions that apply to the user that owns the ﬁle, the group that owns the ﬁle, 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 ﬁrst name speciﬁes the user that owns the ﬁle, and the second name the group that owns the ﬁle. So in the example above, the permissions for user geek are speciﬁed by the ﬁrst set of three characters. User geek has read and write on test, but not execute. Group geek is speciﬁed by the second set of three characters: it also has read and write on test, but not execute. Any other user’s permissions are speciﬁed by the third set of three characters: they only have read permission on test.
The most speciﬁc 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 ﬁle permissions interact. For these examples, we have four users with the following group memberships:
Those users will be working with ﬁles in the dir directory. This is a long listing of the ﬁles 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 ﬁles, including the special ﬁles used to represent the directory and its parent. In this example, . reﬂects the permissions of dir itself, and .. the permissions of its parent directory.
What are the permissions of rfile1? The user that owns the ﬁle (database1) has read and write but not execute. The group that owns the ﬁle (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:
|EFFECT||WHY IS THIS TRUE?|
|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.|
How to change the permissions and ownership of files in Linux
Understanding Linux Special permissions – Sticky Bit, SUID, SGID
How to Control the default permissions of new files created by users using “umask”