Editing File-system permissions (section)

==Traditional POSIX permissions==
{{anchor|Notation of traditional Unix permissions}}

Traditionally, file permissions on a Unix-based file system is defined by POSIX.1-2017,<ref>{{Cite web |date=2018-07-22 |title=Definitions, 3.175 File Permission Bits |url=https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_175 |access-date=2023-06-24 |website=pubs.opengroup.org}}</ref>. 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 <code>[[umask]]</code> command.

In a Unix-based file system, everything is a file; even [[Unix file type|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 identifier|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.

===Operations===
The operations that can be granted or denied include:
* ''Read'' grants the ability to read a file. When set for a directory, this permission grants the ability to read the names of contained files, but not to read other information about them such as contents, file type, size, ownership, permissions.
* ''Write'' grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory, which includes creating, deleting and renaming files. This requires that ''execute'' is also set; without it, the write permission is meaningless for directories.
* ''Execute'' grants the ability to execute a file. This permission must be set for executable programs to allow running them. When set for a directory, this permission is interpreted as the ''search'' permission {{endash}} granting the ability to access file contents and metadata if its name is known, but not list files in the directory, unless ''read'' is set also.

The effect of setting the permissions on a directory, rather than a file, is "one of the most frequently misunderstood file permission issues".<ref>{{cite web |last=Hatch |first=Bri |url=http://www.hackinglinuxexposed.com/articles/20030424.html |title=Linux File Permission Confusion pt 2 |website=Hacking Linux Exposed |date=April 24, 2003 |access-date=July 6, 2011}}</ref>

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 ''[[Setuid|set user ID]]'', ''setuid'', or SUID mode. Executing a file with this bit set results in a process with [[User identifier (Unix)|user ID]] set to the file's owning user. This enables users to be treated temporarily as root (or another user).
* The ''[[Setgid|set group ID]]'', ''setgid'', or SGID permission. Executing a file with this bit set results in a process with [[Group identifier (Unix)|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 bit|sticky]]'' mode (also known as the ''Text'' mode). The classical behavior of the sticky bit on executable files has been to encourage the [[Kernel (operating system)|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 <code>ls -l</code>.

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 {{code|r}} for read, {{code|w}} for write or {{code|x}} for execute. 

Examples:
* <code>-rwxr-xr-x</code>: initial {{code|-}} indicates a regular file, next three {{code|rwx}} indicate that user class has all permissions and group and others classes (both {{code|r-x}}) have only read and execute
* <code>crw-rw-r--</code>: initial {{code|c}} indicates a character special file, user and group classes (both {{code|rw-}}) have read and write permissions and others class ({{code|r--}}) has only read permission
* <code>dr-x------</code>: initial {{code|d}}) indicates a directory, user class ({{code|r-x}}) has read and execute permissions and group and others classes (both {{code|---}}) 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, <code>x</code> becomes <code>s</code> and <code>-</code> becomes <code>S</code>. For the sticky or text attribute <code>x</code> becomes <code>t</code> and <code>-</code> becomes <code>T</code>. For example <code>-rwsr-Sr-t</code> 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:
* {{code|+}} suffix indicates an access control list that can control additional permissions
* {{code|.}} suffix indicates an [[SELinux]] context is present.  Details may be listed with the command <code>ls -Z</code>
* {{code|@}} suffix indicates [[extended file attributes]] are present

====Octal notation====
Permissions are often shown in [[octal]] notation; for example via the command <code>stat -c %a</code>. 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 [[Logical disjunction|logic OR]] of the grants.

Examples:
{| class="wikitable" style="text-align: center;"
|-
! Symbolic !! Octal !! Description
|-
| style="text-align: center;" | <code>----------</code> || 0000 || style="text-align: left" | no permissions
|-
| style="text-align: center;" | <code>-rwx------</code> ||0700|| style="text-align: left" | read, write, & execute only for owner
|-
| style="text-align: center;" | <code>-rwxrwx---</code> || 0770 || style="text-align: left" | read, write, & execute for owner and group
|-
| style="text-align: center;" | <code>-rwxrwxrwx</code> || 0777 || style="text-align: left" | read, write, & execute for owner, group and others
|-
| style="text-align: center;" | <code>-rwxr-----</code> || 0740 || style="text-align: left" | owner can read, write, & execute; group can only read; others have no permissions
|-
|}
<!--

Here is a list of the meanings for individual octal digit values:

 0 --- no permission
 1 --x execute
 2 -w- write
 3 -wx write and execute
 4 r-- read
 5 r-x read and execute
 6 rw- read and write
 7 rwx read, write, and execute

Here some example showing which digits affect permissions for user, group, and other:
* 754 = <code>"-rwxr-xr--"</code>  = rwx for owner, r-x for group, r-- for other
* 124 = <code>"---x-w-r--"</code>  = 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, <code>"-rwsr-Sr-x"</code> would be represented as <code>6745</code> in four-digit octal. In addition, the examples in the previous section (<code>755</code>, <code>664</code>, and <code>500</code>) would be represented as <code>0755</code>, <code>0664</code>, and <code>0500</code> respectively in four-digit octal notation.
-->