File system permissions
Most file systems have methods to assign permissions or access rights to specific users and groups of users. These permissions control the ability of the users to view, change, navigate, and execute the contents of the file system. In some cases, menu options or functions may be made visible or hidden depending on a user's permission level; this kind of user interface is referred to as permission-driven.
Two types of permissions are very widely used: traditional Unix permissions date back many decades to the earliest days of Unix. They are universally available on all Unix and Linux derived platforms. Access Control Lists are more recent in origin and are universally used on Microsoft Windows based file systems where the file system supports user permissions, and are also now commonly used and widely available in most common Unix and Linux based systems, although not necessarily all. They are generally capable of far more detailed fine-tuning of permissions than the traditional Unix permissions, and permit a system of access control which traditional ACLs cannot provide. On Unix and Linux based systems, the standard type of ACL is that defined by the POSIX standard but other variants exist such as NFS v3 and v4 ACLs, which work slightly differently.
Where multiple systems are available within the same operating system, there is usually a way to specify which will be used for any given file system, and how the system should handle attempts to access or modify permissions that are controlled by one of these, using commands designed for another. The usual solution is to ensure at least some degree of awareness and inter-operability between the different commands and methods.
Operating system variations
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, either proprietary, 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 do not have permissions, only file attributes. There is a read-only attribute, which can be set or unset on a file by any user or program, and therefore does not prevent anyone 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 loaded.
OpenVMS, as well as Microsoft Windows NT and its derivatives, 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 and four types of access permissions. The categories are not mutually disjoint: World includes Group which in turn includes Owner. The System category independently includes system users.
Classic Mac OS operating systems' HFS do not support permissions, only file attributes: "Hidden" ; "Locked" ; "Name locked" ; and "Stationery".
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 permissions/flags. In AmigaOS 2.x and higher, additional Hold, Script, and Pure permissions/flags were added.
Mac OS X versions 10.3 and prior use POSIX-compliant permissions. Mac OS X, beginning with version 10.4, 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.
Solaris ACL support depends on the filesystem being used; older UFS filesystem supports POSIX.1e ACLs, while ZFS supports only NFSv4 ACLs.
Linux supports POSIX.1e ACLs. There is experimental support for NFSv4 ACLs for ext3 filesystem and ext4 filesystem.
FreeBSD supports POSIX.1e ACLs on UFS, and NFSv4 ACLs on UFS and ZFS.
IBM z/OS implements file security via RACF
Traditional Unix permissions
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.
Classes
and directories are owned by a user. The owner determines the file's user class. Distinct permissions apply to the owner.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.
Permissions
systems implement three specific permissions that apply to each class:- The read permission grants the ability to read a file. When set for a directory, this permission grants the ability to read the names of files in the directory, but not to find out any further information about them such as contents, file type, size, ownership, permissions.
- The write permission 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 files, deleting files, and renaming files. Note that this requires that execute is also set; without it, the write permission is meaningless for directories.
- The execute permission grants the ability to execute a file. This permission must be set for executable programs, in order to allow the operating system to run them. When set for a directory, the execute permission is interpreted as the search permission: it grants the ability to access file contents and meta-information if its name is known, but not list files inside the directory, unless read is set also.
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.
Changing permission behavior with setuid, setgid, and sticky bits
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] 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.- The set user ID, setuid, or SUID mode. When a file with setuid is executed, the resulting process will assume the effective user ID given to the owner class. This enables users to be treated temporarily as root.
- The set group ID, setgid, or SGID permission. When a file with setgid is executed, the resulting process will assume the group ID given to the group class. When setgid is applied to a directory, new files and directories created under that directory will inherit their group from that directory.
- The sticky mode. The classical behaviour 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. 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.
Notation of traditional Unix permissions
Symbolic notation
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.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:
-
rif reading is permitted,-if it is not. -
wif writing is permitted,-if it is not. -
xif execution is permitted,-if it is not.
-
-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.
ls -l display represent 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.
-
-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.Numeric notation
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. 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:
- The read bit adds 4 to its total,
- The write bit adds 2 to its total, and
- The execute bit adds 1 to its total.
These are the examples from the symbolic notation section given in octal notation:
| Symbolic Notation | Numeric Notation | English |
---------- | 0000 | no permissions |
-rwx------ | 0700 | read, write, & execute only for owner |
-rwxrwx--- | 0770 | read, write, & execute for owner and group |
-rwxrwxrwx | 0777 | read, write, & execute for owner, group and others |
---x--x--x | 0111 | execute |
--w--w--w- | 0222 | write |
--wx-wx-wx | 0333 | write & execute |
-r--r--r-- | 0444 | read |
-r-xr-xr-x | 0555 | read & execute |
-rw-rw-rw- | 0666 | read & write |
-rwxr----- | 0740 | owner can read, write, & execute; group can only read; others have no permissions |