Typically, afile system maintainspermission settings for each stored item – commonlyfiles anddirectories – that either grant or deny the ability to manipulate file system items. Often the settings allow controlling access based on function such as read, change, navigate, andexecute and to differentusers and groups of users. One well-established technology was developed forUnix and later codified byPOSIX. Another common technology is anaccess-control list (ACL) with multiple variants implemented in file systems and one codified by POSIX. Since POSIX defines both the older Unix-based technology as well as ACLs, the former is calledtraditional POSIX permissions for clarity even though it is not a well-known term.

Apermission-driven user interface tailors the functionality available to the user based on file system item permissions. For example, the interface might hide menu options that are not allowed based on the permissions stored for an item.

File system permissions have been implemented many ways. Some notable examples are described here.

NTFS which is in many versions ofWindows includingthe current, uses ACL technology to provide permission-based access control; considered powerful yet complex.^[1]

Linux file systems such asext2,ext3,ext4,Btrfs support both POSIX permissions and POSIX.1e ACLs. There is experimental support for NFSv4 ACLs for ext3^[2] and ext4 filesystems.

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

HFS, and its successorHFS+, as implemented in theClassic Mac OS operating systems, do not support permissions.

macOS supports POSIX-compliant permissions, and supports them in both HFS+ andAPFS. Beginning with version 10.4 ("Tiger"), it also supports the use of NFSv4 ACLs in addition to POSIX-compliant permissions. TheApple 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"/"Locked" attribute as the "user immutable" flag inthe 4.4BSD flags field.^[5]

File Allocation Table (original version) has a per-file read-only attribute that applies to all users.

OpenVMS defines four access functions: read, write, execute and delete and user selections: system, owner, group, and world where world includes group which in turn includes owner and system selects system users. This design is similar to that of Unix with notable extensions: additional function: delete and additional user selection: system.^[6] ACLs are supported in VMS 4.0 and later.^[7]

Solaris ACL support depends on the filesystem being used; olderUFS filesystem supports POSIX.1e ACLs, whileZFS supports only NFSv4 ACLs.^[8]

IBM z/OS implements file security using RACF (Resource Access Control Facility)^[9]

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 andHarmonyOS withHarmonyOS NEXT versions and alsoLinux-basedopenEuler 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.^{[10][failed verification]}

Traditionally, file permissions on a Unix-based file system is defined by POSIX.1-2017,^[11]. 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 theumask command.

In a Unix-based file system, everything is a file; evendirectories and other special files.

The classes determine how permissions map to a user. Theuser class permissions apply to the user who owns the file. Thegroup class permissions apply to users of the file's owninggroup. Theothers class applies to other users.

Theeffective permissions are the permissions of the class in which the user fallsfirst 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.

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 thatexecute 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 thesearch permission – granting the ability to access file contents and metadata if its name is known, but not list files in the directory, unlessread 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".^[12]

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.

Three additional single-bit attributes apply to each file that are related to permissions and stored in the file mode along with permissions.

• Theset user ID,setuid, or SUID mode. Executing a file with this bit set results in a process withuser ID set to the file's owning user. This enables users to be treated temporarily as root (or another user).
• Theset group ID,setgid, or SGID permission. Executing a file with this bit set results in a process withgroup 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 (seeSetuid).)
• Thesticky mode (also known as theText mode). The classical behavior of the sticky bit on executable files has been to encourage thekernel 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 andUnixWare). 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.

Permissions are commonly represented in symbolic or octal notation.

Symbolic notation is used in the long output format of commandls -l.

The first character of the output indicates theUnix 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 asr for read,w for write orx for execute.

Examples:

• -rwxr-xr-x: initial- indicates a regular file, next threerwx indicate that user class has all permissions and group and others classes (bothr-x) have only read and execute
• crw-rw-r--: initialc indicates a character special file, user and group classes (bothrw-) have read and write permissions and others class (r--) has only read permission
• dr-x------: initiald) indicates a directory, user class (r-x) has read and execute permissions and group and others classes (both---) have no permissions

To represent thesetuid,setgid andsticky/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 becomess and- becomesS. For the sticky or text attributex becomest and- becomesT. 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 hassetuid,setgid andsticky attributes set.

Some systems show additional permission features:

• + suffix indicates an access control list that can control additional permissions
• . suffix indicates anSELinux context is present. Details may be listed with the commandls -Z
• @ suffix indicatesextended file attributes are present

Permissions are often shown inoctal notation; for example via the commandstat -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 andsticky.

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 thelogic OR of the grants.

Examples:

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.^[13][14]

• chattr or chflags – Change attributes or flags including those which restrict access
• chmod – Shell command for changing access permissions of a file
• lsattr List attributes
• Comparison of file systems § Metadata

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

• File system permissions

• Use American English from January 2019
• All Wikipedia articles written in American English
• Articles with short description
• Short description is different from Wikidata
• All articles with failed verification
• Articles with failed verification from July 2024