File-system permissions

Last updated December 16, 2024

Most file systems include attributes of files and directories that control the ability of users to read, 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.

File system variations

The original File Allocation Table file system has a per-file all-user read-only attribute.

NTFS implemented in Microsoft Windows NT and its derivatives, use ACLs^[1] to provide a complex set of permissions.

OpenVMS uses a permission scheme similar to that of Unix. 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.^[2]

HFS, and its successor HFS+, as implemented in the Classic Mac OS operating systems, do not support permissions.

macOS uses POSIX-compliant permissions, and supports them in both HFS+ and APFS. Beginning with version 10.4 ("Tiger"), it also supports the use of NFSv4 ACLs in addition to POSIX-compliant permissions. The Apple Mac OS X Server version 10.4+ File Services Administration Manual recommends using only traditional Unix permissions if possible. macOS also still supports the Classic Mac OS'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.^[3]

Linux supports ext2, ext3, ext4, Btrfs and other file systems many of which include POSIX.1e ACLs. There is experimental support for NFSv4 ACLs for ext3^[4] and ext4 filesystems.

FreeBSD supports POSIX.1e ACLs on UFS, and NFSv4 ACLs on UFS and ZFS.^[5]^[6]

IBM z/OS implements file security using RACF (Resource Access Control Facility)^[7]^{[ permanent dead link ‍]}

The AmigaOS Filesystem, AmigaDOS supports a permissions system relatively advanced 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.

OpenHarmony operating system alongside its client side ecosystem in Oniro OS and HarmonyOS with HarmonyOS NEXT versions and also Linux-based openEuler server OS natively uses its Harmony Distributed File System (HMDFS) that supports access token manager (role-based access control) and Core File Kit API capability-based with granular permission management with exception to openEuler.^[8]^{[ failed verification ]}

POSIX permissions

Permissions on Unix-like file systems are defined in the POSIX.1-2017 standard,^[9] which uses three scopes or classes known as owner, group, and others. When a file is created its permissions are restricted by the umask of the process that created it.

Classes

Files 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

Unix-like 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. 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.

The effect of setting the permissions on a directory, rather than a file, is "one of the most frequently misunderstood file permission issues".^[10]

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

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.

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 (or another user).
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. (Default behaviour 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 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 (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.

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.

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.


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
Each triad
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:

r if reading is permitted, - if it is not.
w if writing is permitted, - if it is not.
x if execution is permitted, - if it is not.

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:

+ (plus) suffix indicates an access control list that can control additional permissions.
. (dot) suffix indicates an SELinux context is present. Details may be listed with the command ls -Z.
@ suffix indicates extended file attributes are present.

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.

Numeric notation

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:

The read bit adds 4 to its total (in binary 100),
The write bit adds 2 to its total (in binary 010), and
The execute bit adds 1 to its total (in binary 001).

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
`----------`	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

User private group

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 that 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.^[11]^[12]

Related Research Articles

A Unix shell is a command-line interpreter or shell that provides a command line user interface for Unix-like operating systems. The shell is both an interactive command language and a scripting language, and is used by the operating system to control the execution of the system using shell scripts.

In Unix and Unix-like operating systems, chmod is the command and system call used to change the access permissions and the special mode flags of file system objects. Collectively these were originally called its modes, and the name chmod was chosen as an abbreviation of change mode.

In computer security, an access-control list (ACL) is a list of permissions associated with a system resource. An ACL specifies which users or system processes are granted access to resources, as well as what operations are allowed on given resources. Each entry in a typical ACL specifies a subject and an operation. For instance,

In computing, tar is a computer software utility for collecting many files into one archive file, often referred to as a tarball, for distribution or backup purposes. The name is derived from "tape archive", as it was originally developed to write data to sequential I/O devices with no file system of their own, such as devices that use magnetic tape. The archive data sets created by tar contain various file system parameters, such as name, timestamps, ownership, file-access permissions, and directory organization. POSIX abandoned tar in favor of pax, yet tar sees continued widespread use.

In computing, ls is a command to list computer files and directories in Unix and Unix-like operating systems. It is specified by POSIX and the Single UNIX Specification.

The mkdir command in the Unix, DOS, DR FlexOS, IBM OS/2, Microsoft Windows, and ReactOS operating systems is used to make a new directory. It is also available in the EFI shell and in the PHP scripting language. In DOS, OS/2, Windows and ReactOS, the command is often abbreviated to md.

The inode is a data structure in a Unix-style file system that describes a file-system object such as a file or a directory. Each inode stores the attributes and disk block locations of the object's data. File-system object attributes may include metadata, as well as owner and permission data.

fstab is a system file commonly found in the directory /etc on Unix and Unix-like computer systems. In Linux, it is part of the util-linux package. The fstab file typically lists all available disk partitions and other types of file systems and data sources that may not necessarily be disk-based, and indicates how they are to be initialized or otherwise integrated into the larger file system structure.

stat is a Unix system call that returns file attributes about an inode. The semantics of stat vary between operating systems. As an example, Unix command ls uses this system call to retrieve information on files that includes:

In computing, umask is a command that determines the settings of a mask that controls how file permissions are set for newly created files. It may also affect how the file permissions are changed explicitly. umask is also a function that sets the mask, or it may refer to the mask itself, which is formally known as the file mode creation mask. The mask is a grouping of bits, each of which restricts how its corresponding permission is set for newly created files. The bits in the mask may be changed by invoking the umask command.

The Unix and Linux access rights flags setuid and setgid allow users to run an executable with the file system permissions of the executable's owner or group respectively and to change behaviour in directories. They are often used to allow users on a computer system to run programs with temporarily elevated privileges to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.

In Unix-like systems, multiple users can be put into groups. POSIX and conventional Unix file system permissions are organized into three classes, user, group, and others. The use of groups allows additional abilities to be delegated in an organized fashion, such as access to disks, printers, and other peripherals. This method, among others, also enables the superuser to delegate some administrative tasks to normal users, similar to the Administrators group on Microsoft Windows NT and its derivatives.

The seven standard Unix file types are regular, directory, symbolic link, FIFO special, block special, character special, and socket as defined by POSIX. Different OS-specific implementations allow more types than what POSIX requires. A file's type can be identified by the ls -l command, which displays the type in the first character of the file-system permissions field.

File locking is a mechanism that restricts access to a computer file, or to a region of a file, by allowing only one user or process to modify or delete it at a specific time, and preventing reading of the file while it's being modified or deleted.

Unix-like operating systems identify a user by a value called a user identifier, often abbreviated to user ID or UID. The UID, along with the group identifier (GID) and other access control criteria, is used to determine which system resources a user can access. The password file maps textual user names to UIDs. UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service. In POSIX-compliant environments, the shell command id gives the current user's UID, as well as more information such as the user name, primary user group and group identifier (GID).

A command shell is a command-line interface to interact with and manipulate a computer's operating system.

File attributes are a type of metadata that describe and may modify how files and/or directories in a filesystem behave. Typical file attributes may, for example, indicate or specify whether a file is visible, modifiable, compressed, or encrypted. The availability of most file attributes depends on support by the underlying filesystem where attribute data must be stored along with other control structures. Each attribute can have one of two states: set and cleared. Attributes are considered distinct from other metadata, such as dates and times, filename extensions or file system permissions. In addition to files, folders, volumes and other file system objects may have attributes.

In computing, the sticky bit is a user ownership access right flag that can be assigned to files and directories on Unix-like systems.

Extended file attributes are file system features that enable users to associate computer files with metadata not interpreted by the filesystem, whereas regular attributes have a purpose strictly defined by the filesystem. Unlike forks, which can usually be as large as the maximum file size, extended attributes are usually limited in size to a value significantly smaller than the maximum file size. Typical uses include storing the author of a document, the character encoding of a plain-text document, or a checksum, cryptographic hash or digital certificate, and discretionary access control information.

Richacls is a Linux implementation of the NFSv4 ACLs which has been extended by file masks to more easily fit the proprietary POSIX draft file permission model. Nowadays, they offer the most complex permission model for ext4 file system in Linux. They are even more complex than POSIX draft ACLs, which means it is not possible to convert back from Richacls to Linux' implementation of the POSIX draft ACLs without losing information. One of the most important advantages is that they distinguish between write and append permission, between delete and delete child permissions, and make ACL management access discretionary. They are also designed to support Windows interoperability.

References

↑ "File and Folder Permissions". Microsoft. 9 December 2009.
↑ "OpenVMS documentation". Archived from the original on 2012-03-05. Retrieved 2009-06-06.
↑ "Oracle Solaris ZFS Administration Guide" (PDF). Sep 2010.
↑ "Native NFSv4 ACLs on Linux". Archived from the original on 2008-10-12. Retrieved 2010-05-04.
↑ "NFSv4_ACLs – FreeBSD Wiki".
↑ "FreeNAS 9.1.1 Users Guide" (PDF). 2013.
↑ "IBM Knowledge Center".
↑ "HarmonyOS Distributed File System Development Guide". Substack. LivingInHarmony Blog. 13 March 2024. Retrieved 13 March 2024.
↑ "Definitions, 3.175 File Permission Bits". pubs.opengroup.org. 2018-07-22. Retrieved 2023-06-24.
↑ Hatch, Bri. "Linux File Permission Confusion pt 2", "Hacking Linux Exposed", April 24, 2003, accessed July 6, 2011.
↑ Epstein, Brian. "The How and Why of User Private Groups in Unix". security.ias.edu. Institute for Advanced Study Network Security. Archived from the original on 8 August 2014. Retrieved 5 August 2014.
↑ "Red Hat Enterprise Linux 7 System Administrator's Guide, 4.3.4 Creating Group Directories". Red Hat Customer Portal. Red Hat.

External links

The Linux Cookbook: Groups and How to Work in Them by Michael Stutz 2004

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] "File and Folder Permissions". Microsoft. 9 December 2009.

[2] "OpenVMS documentation". Archived from the original on 2012-03-05. Retrieved 2009-06-06.

[3] "Oracle Solaris ZFS Administration Guide" (PDF). Sep 2010.

[4] "Native NFSv4 ACLs on Linux". Archived from the original on 2008-10-12. Retrieved 2010-05-04.

[5] "NFSv4_ACLs – FreeBSD Wiki".

[6] "FreeNAS 9.1.1 Users Guide" (PDF). 2013.

[7] "IBM Knowledge Center".

[8] "HarmonyOS Distributed File System Development Guide". Substack. LivingInHarmony Blog. 13 March 2024. Retrieved 13 March 2024.

[9] "Definitions, 3.175 File Permission Bits". pubs.opengroup.org. 2018-07-22. Retrieved 2023-06-24.

[10] Hatch, Bri. "Linux File Permission Confusion pt 2", "Hacking Linux Exposed", April 24, 2003, accessed July 6, 2011.

[11] Epstein, Brian. "The How and Why of User Private Groups in Unix". security.ias.edu. Institute for Advanced Study Network Security. Archived from the original on 8 August 2014. Retrieved 5 August 2014.

[12] "Red Hat Enterprise Linux 7 System Administrator's Guide, 4.3.4 Creating Group Directories". Red Hat Customer Portal. Red Hat.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

v t e Computer files
Types	Binary file / text file Data file File format List of file formats File signatures Magic number Open file formats Proprietary file formats Metafile Sidecar file Sparse file Swap file System file Temporary file Zero-byte file
Properties	Filename 8.3 filename Long filename Filename mangling Filename extension List of filename extensions File attribute Extended file attributes File size Hidden file / Hidden directory
Organisation	Directory/folder NTFS links Temporary folder Directory structure File system Filesystem Hierarchy Standard Grid file system Semantic file system Path
Operations	Open Close Read Write
Linking	File descriptor Hard link Shortcut Alias Shadow Symbolic link
Management	Backup File comparison File copying Data compression File manager Comparison of file managers File system fragmentation File-system permissions File transfer File sharing File synchronization File verification