Most file systems have methods to assign permissions or access rights to specific users and groups of users. These systems control the ability of the users to view, change, navigate, and execute the contents of the file system.
Unix-like and otherwise POSIX-compliant systems, including Linux-based systems and all macOS versions, have a simple system for managing individual file permissions, which in this article are called "traditional Unix permissions". Most of these systems also support some kind of access control lists (ACLs), either proprietary (old HP-UX ACLs, for example), or POSIX.1e ACLs, based on an early POSIX draft that was withdrawn in 1997, or NFSv4 ACLs, which are part of the NFSv4 standard.
Microsoft and IBM DOS variants (including MS-DOS, PC DOS, Windows 95, Windows 98, Windows 98 SE, and Windows ME) do not have permissions, only file attributes. There is a read-only attribute (R), which can be set or unset on a file by any user or program, and therefore does not prevent him/her/it from changing/deleting the file. There is no permission in these systems which would prevent a user from reading a file.
Other MS-DOS/PC DOS-compatible operating systems such as DR DOS 3.31 and higher, PalmDOS, Novell DOS and OpenDOS, FlexOS, 4680 OS, 4690 OS, Concurrent DOS, Multiuser DOS, Datapac System Manager and IMS REAL/32 support read/write/execute/delete file/directory access permissions on FAT volumes. With the exception of FlexOS, 4680 OS, and 4690 OS all these operating systems also support individual file/directory passwords. All operating systems except for DR DOS, PalmDOS, Novell DOS and OpenDOS also support three independent file/directory ownership classes world/group/owner, whereas the single-user operating systems DR DOS 6.0 and higher, PalmDOS, Novell DOS and OpenDOS only support them with an optional multi-user security module (SECURITY.BIN) loaded.
OpenVMS (a.k.a. VMS), as well as Microsoft Windows NT and its derivatives (including Windows 2000 and Windows XP), use ACLs to administer a more complex and varied set of permissions. OpenVMS also uses a permission scheme similar to that of Unix, but more complex. There are four categories (System, Owner, Group, and World) and four types of access permissions (Read, Write, Execute and Delete). The categories are not mutually disjoint: World includes Group which in turn includes Owner. The System category independently includes system users (similar to superusers in Unix).
Classic Mac OS operating systems' HFS do not support permissions, only file attributes: "Hidden" (does not show in directory listings); "Locked" (read-only); "Name locked" (cannot be renamed); and "Stationery" (copy-on-write).
The AmigaOS Filesystem, AmigaDOS supports a relatively advanced permissions system, for a single-user OS. In AmigaOS 1.x, files had Archive, Read, Write, Execute and Delete (collectively known as ARWED) permissions/flags. In AmigaOS 2.x and higher, additional Hold, Script, and Pure permissions/flags were added.
Mac OS X versions 10.3 ("Panther") and prior use POSIX-compliant permissions. Mac OS X, beginning with version 10.4 ("Tiger"), also support the use of NFSv4 ACLs. They still support "traditional Unix permissions" as used in previous versions of Mac OS X, and the Apple Mac OS X Server version 10.4+ File Services Administration Manual recommends using only traditional Unix permissions if possible. It also still supports the Mac OS Classic's "Protected" attribute.
Permissions on Unix-like systems are managed in three distinct scopes or classes. These scopes are known as user, group, and others.
When a file is created on a Unix-like system, its permissions are restricted by the umask of the process that created it.
Files and directories are assigned a group, which define the file's group class. Distinct permissions apply to members of the file's group. The owner may be a member of the file's group.
Users who are not the owner, nor a member of the group, comprise a file's others class. Distinct permissions apply to others.
The effective permissions are determined based on the first class the user falls within in the order of user, group then others. For example, the user who is the owner of the file will have the permissions given to the user class regardless of the permissions assigned to the group class or others class.
Unix-like systems implement three specific permissions that apply to each class:
The effect of setting the permissions on a directory, rather than a file, is "one of the most frequently misunderstood file permission issues".
When a permission is not set, the corresponding rights are denied. Unlike ACL-based systems, permissions on Unix-like systems are not inherited. Files created within a directory do not necessarily have the same permissions as that directory.
Unix-like systems typically employ three additional modes. These are actually attributes but are referred to as permissions or modes. These special modes are for a file or directory overall, not by a class, though in the symbolic notation (see below) the setuid bit is set in the triad for the user, the setgid bit is set in the triad for the group and the sticky bit is set in the triad for others.
These additional modes are also referred to as setuid bit, setgid bit, and sticky bit, due to the fact that they each occupy only one bit.
Unix permissions are represented either in symbolic notation or in octal notation.
The most common form, as used by the command ls -l, is symbolic notation.
|Three permission triads|
|first triad||what the owner can do|
|second triad||what the group members can do|
|third triad||what other users can do|
|first character||r: readable|
|second character||w: writable|
|third character||x: executable
s or t: setuid/setgid or sticky (also executable)
S or T: setuid/setgid or sticky (not executable)
The first character of the ls display indicates the file type and is not related to permissions. The remaining nine characters are in three sets, each representing a class of permissions as three characters. The first set represents the user class. The second set represents the group class. The third set represents the others class.
Each of the three characters represent the read, write, and execute permissions:
The following are some examples of symbolic notation:
-rwxr-xr-x: a regular file whose user class has full permissions and whose group and others classes have only the read and execute permissions.
crw-rw-r--: a character special file whose user and group classes have the read and write permissions and whose others class has only the read permission.
dr-x------: a directory whose user class has read and execute permissions and whose group and others classes have no permissions.
In some permission systems additional symbols in the ls -l display represent additional permission features:
To represent the setuid, setgid and sticky or text attributes, the executable character ('x' or '-') is modified. Though these attributes affect the overall file, not only users in one class, the setuid attribute modifies the executable character in the triad for the user, the setgid attribute modifies the executable character in the triad for the group and the sticky or text attribute modifies the executable character in the triad for others. For the setuid or setgid attributes, in the first or second triad, the 'x' becomes 's' and the '-' becomes 'S'. For the sticky or text attribute, in the third triad, the 'x' becomes 't' and the '-' becomes 'T'. Here is an example:
-rwsr-Sr-t: a file whose user class has read, write and execute permissions; whose group class has read permission; whose others class has read and execute permissions; and which has setuid, setgid and sticky attributes set.
Another method for representing Unix permissions is an octal (base-8) notation as shown by stat -c %a. This notation consists of at least three digits. Each of the three rightmost digits represents a different component of the permissions: owner, group, and others. (If a fourth digit is present, the leftmost (high-order) digit addresses three additional attributes, the setuid bit, the setgid bit and the sticky bit.)
Each of these digits is the sum of its component bits in the binary numeral system. As a result, specific bits add to the sum as it is represented by a numeral:
These values never produce ambiguous combinations; each sum represents a specific set of permissions. More technically, this is an octal representation of a bit field - each bit references a separate permission, and grouping 3 bits at a time in octal corresponds to grouping these permissions by user, group, and others.
These are the examples from the symbolic notation section given in octal notation:
|Symbolic Notation||Numeric Notation||English|
||0700||read, write, & execute only for owner|
||0770||read, write, & execute for owner and group|
||0777||read, write, & execute for owner, group and others SECURITY RISK|
||0333||write & execute|
||0555||read & execute|
||0666||read & write|
||0740||owner can read, write, & execute; group can only read; others have no permissions|
Some systems diverge from the traditional POSIX-model of users and groups, by creating a new group - a "user private group" - for each user. Assuming each user is the only member of its user private group, this scheme allows an umask of 002 to be used without allowing other users to write to newly created files in normal directories because such files are assigned to the creating user's private group. However, when sharing files is desirable, the administrator can create a group containing the desired users, create a group-writable directory assigned to the new group, and, most importantly, make the directory setgid. Making it setgid will cause files created in it to be assigned to the same group as the directory and the 002 umask (enabled by using user private groups) will ensure that other members of the group will be able to write to those files. 
Manage research, learning and skills at defaultLogic. Create an account using LinkedIn or facebook to manage and organize your Digital Marketing and Technology knowledge. defaultLogic works like a shopping cart for information -- helping you to save, discuss and share.