Traditionally, file permissions on a Unix-based file system are defined by POSIX.1. It specifies three classes (user, group and others) that allow for mapping permissions to users and three operations (read, write, execute) that can be granted or denied for each class. When a file is created, its permissions default to that as accessible via the
umask command. In a Unix-based file system, everything is a file, even
directories and other special files.
Classes The classes determine how permissions map to a user. The
user class permissions apply to the user who owns the file. The
group class permissions apply to users of the file's owning
group. The
others class applies to other users. The
effective permissions are the permissions of the class in which the user falls
first given the order: user, group then others. For example, the owning user has effective permissions of the user class even if they are in the owning group.
Permissions The following permissions grant the corresponding operations on files and directories:
Read (r) • For files: grants the ability to read the file’s contents (not its name or metadata, which are determined by the permissions of its parent directory). • For directories: grants the ability to read the directory entry names of its contained files and directories, but not to access their metadata (
inode) and therefore their content, which is determined by the directory
execute permission.
Write (w) • For files: grants the ability to modify the file contents. • For directories: grants the ability to modify entries in the directory, which allows creating, deleting, and renaming its files or directories. • Doing so also requires the
execute permission in order to access the metadata (
inode) of all its containing files and directories. Therefore, without
execute permission the
write permission is effectively meaningless.
Execute (x) • For files: grants the ability to execute a file. This permission must be set for executable programs to allow running them. • Doing so also requires the
read permission. • For directories: grants the ability to read the metadata of its containing files and directories if their names are known, but not to read their names. A directory without
execute permission effectively blocks reading and writing the content of its contained files and directories. • A directory with
execute permission but without
read permission effectively makes it a name guessing game to access the contents of its files and directories.
General access requirement inside directories Accessing the content of file or directory inside a directory requires: • Knowing its name which is discoverable if the parent directory
read permission is set (or by guessing its name). • The parent directory
execute permission to access the file or directory
inode. • Its corresponding
read,
write or
execute permissions.
Permission requirement summary for file operations To read from a file you need: • The file
read permission. •
Execute permission on its parent directory . To write to a file you need: • The file
write permission. •
Execute permission on its parent directory . To execute a file you need: • The file
read and
execute permission. •
Execute permission on its parent directory . To know the name of the file you need: •
Read permission of its parent directory . To add, remove, or rename a file you need: •
write, and execute permission on its parent directory.
Notes Metadata of a file or directory typically includes
inode id, file type, size, ownership (GUI and UID), and permission bits. The effect of setting the permissions on a directory, rather than a file, is "one of the most frequently misunderstood file permission issues". Unlike ACL-based systems, these permissions are not inherited. Files created within a directory do not necessarily have the same permissions as its containing directory.
Changing permission behavior with setuid, setgid, and sticky bits Three additional single-bit attributes apply to each file that are related to permissions and stored in the file mode along with permissions. • The
set user ID,
setuid, or SUID mode. Executing a file with this bit set results in a process with
user ID set to the file's owning user. This enables users to be treated temporarily as root (or another user). • The
set group ID,
setgid, or SGID permission. Executing a file with this bit set results in a process with
group ID set to the file's owning group. When applied to a directory, new files and directories created under that directory inherit their group from that directory. (Default behavior is to use the primary group of the effective user when setting the group of new files and directories, except on BSD-derived systems which behave as though the setgid bit is always set on all directories (see
Setuid).) • The
sticky mode (also known as the
Text mode). The classical behavior of the sticky bit on executable files has been to encourage the
kernel to retain the resulting process image in memory beyond termination; however, such use of the sticky bit is now restricted to only a minority of Unix-like operating systems (
HP-UX and
UnixWare). On a directory, the sticky permission prevents users from renaming, moving or deleting contained files owned by users other than themselves, even if they have write permission to the directory. Only the directory owner and superuser are exempt from this.
Representation Permissions are commonly represented in symbolic or octal notation.
Symbolic notation Symbolic notation is used in the long output format of command ls -l. The first character of the output indicates the
Unix file type which is not a permission even though its next to the permissions information. The remaining nine characters represent the grants for the user, group and others classes as groups of operation grants for read, write and execute. An operation is denied when shown as a dash or granted when shown as for read, for write or for execute. Examples: • -rwxr-xr-x: initial indicates a regular file, next three indicate that user class has all permissions and group and others classes (both ) have only read and execute • crw-rw-r--: initial indicates a character special file, user and group classes (both ) have read and write permissions and others class () has only read permission • dr-x------: initial indicates a directory, user class () has read and execute permissions and group and others classes (both ) have no permissions To represent the
setuid,
setgid and
sticky/text attributes, the character in the third position for a class is modified, even though this position is otherwise only for execute and even though these attributes affect the file without concern for class. The setuid attribute modifies the execute character for the user class, the setgid attribute modifies the execute character for the group class, and the sticky or text attribute modifies the execute character for the others class. For setuid or setgid, x becomes s and - becomes S. For the sticky or text attribute x becomes t and - becomes T. For example -rwsr-Sr-t indicates a regular file, user class has read, write and execute permissions; group class has read permission; others class has read and execute permissions; and which has
setuid,
setgid and
sticky attributes set. Some systems show additional permission features: • suffix indicates an access control list that can control additional permissions • suffix indicates an
SELinux context is present. Details may be listed with the command ls -Z • suffix indicates
extended file attributes are present
Octal notation Permissions are often shown in
octal notation, for example via the command stat -c %a. The notation consists of at least three digits. The last three digits represent the permission by class: user, group, and others. If a fourth digit is present, the leftmost represents the three special attributes:
setuid,
setgid and
sticky. Each operation grant is assigned a bit position that for an octal digit is: • Read: left, binary 100, octal 4 • Write: middle, binary 010, octal 2 • Execute: right, binary 001, octal 1 A class permission value is the sum or alternatively the
logic OR of the grants. Examples: "-rwxr-xr--" = rwx for owner, r-x for group, r-- for other • 124 = "---x-w-r--" = x for owner, w for group, r for other no permissions at all!
Numeric notation and additional permissions There is also a
four-digit form of numeric notation. In this scheme, the standard three digits described above become the last three digits. The first digit represents the additional permissions. On some systems, this first digit cannot be omitted; it is therefore common to use all four digits (where the first digit is zero). This first digit is also the sum of component bits: • The setuid bit adds 4 to the total, • The setgid bit adds 2 to the total, and • The sticky bit adds 1 to the total. The example from the
Symbolic notation and additional permissions section, "-rwsr-Sr-x" would be represented as 6745 in four-digit octal. In addition, the examples in the previous section (755, 664, and 500) would be represented as 0755, 0664, and 0500 respectively in four-digit octal notation. --> ==User private group==