File-system permissions (original) (raw)

Technology for controlling access to file system items

Typically, a file system maintains permission settings for each stored item – commonly files and directories – 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, and execute and to different users and groups of users.

One well-established technology was developed for Unix and later codified by POSIX. Another common technology is an access-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 called traditional POSIX permissions for clarity even though it is not a well-known term.

A permission-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.

An early time-sharing system, the Compatible Time-Sharing System (CTSS), supported multiple users; each user's account had a "problem number" and "programmer number".[1]

The first version of the CTSS file system supported only two "read-only" file modes, one of which can be unset by the user and the other of which can only be unset with edit cards submitted to the computer center.[1]: 45–46 Files can be shared between users in the same project; shared files are assigned to programmer number zero.[1]: 24 There is no protection other than that provided by the read-only bits.

The second version of the file system has separate permission bits for "read-only" and "write-only"; the latter allows only appending to the file. It also has a "private" bit, allowing only the author of the file to access it, and a "protected" bit, allowing only the author of the file to change the file's permissions.[2]

Users on the Multics time-sharing system have a "Person_id", and projects have a "Project_id"; a user logs on to the system with their Person_id and a Project_id. A file has an access control list (ACL), with entries containing a Person_id or a "*", a Project_id or a "*", and an "instance tag" or a "*". An instance tag represents a type of process; an "a", for example, represents a process from a regular interactive session. The entries in an ACL are matched against the process's Person_id, Project_id, and instance tag; an "*" is a wildcard that matches all Person_ids, Project_Ids, or instance tags. The ACL entry that matches with the fewest wildcards is the one that is used.[3]: 6–2, 6-4­6-8

An ACL for a file has access permissions of "read", "write", and "execute"; an ACL for a directory has access permissions of "status" (allows reading attributes of files and directories in the directory), "modify" (allows modification of attributes of files and directories in the directory and removing items from the directory), and "append" (allows adding new items to the directory).[3]: 6-3

A user in TENEX belongs to a set of groups.[4]: 44

A file or directory has a set of permission bits, with six bits for permissions for the file or directory's owner, six bits for permissions for other users in the file's or directory's group, and six bits for other users. For a file, the permission bits are "read", "write", "execute", "append", and "each page of the file has its own permissions", with the sixth bit not being used. For a directory, the permission bits are "access allowed" (if not set, no access to the directory is allowed), "files in the directory may be opened" (subject to the file's permission bits), "owner-like functions may be performed without the file's password", and "files may be added to the directory", with the fifth and sixth bits not being used.[4]: 42–44

A user account in TOPS-10 has a programmer number and a project number.

A file has a set of permission bits, with three bits for permissions for the file's owner, three bits for permissions for other users with the same project number as the owner, and three bits for all other users. The operating system may be configured to treat any account with a programmer number that is the same as the programmer number of the containing directory as the owner or to treat only an account with the same programmer number and project number as those of the containing directory as the owner. The values for the permission bits are:

• 7 - no access privileges, except that the owner may look up the file in order to change its permissions;
• 6 - execute-only;
• 5 - read and execute;
• 4 - append, read, and execute;
• 3 - update, append, read, and execute;
• 2 - write, update, append, read, and execute;
• 1 - rename, write, update, append, read, and execute;
• 0 - change permissions, rename, write, update, append, read, and execute.

The owner is always allowed to change the permissions.[5]

UNIX and Unix-like systems

[edit]

Files in the first edition of Unix (v1) had five bits of permission:

• write, non-owner;
• read, non-owner;
• write, owner;
• read, owner;
• executable;

and a set-UID bit.[6] It had no notion of groups. This continued until the third edition (v3);[7] the fourth edition (v4) introduced groups, and files in v4 had nine bits of permission:

• read, owner;
• write, owner;
• execute, owner;
• read, group;
• write, group;
• execute, group;
• read, other;
• write, other;
• execute, other;

as well as a set-UID and set-GID bit;[8] This is the same set of permissions that are specified in POSIX and that are provided by current Unix and Unix-like systems.

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

NTFS which is in many versions of Windows including the current, uses ACLs to provide permission-based access control; NTFS ACLs are considered powerful yet complex.[9]

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

FreeBSD supports POSIX.1e ACLs on UFS, and NFSv4 ACLs on UFS and ZFS.[11][12]

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

macOS supports 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"/"Locked" attribute as the "user immutable" flag in the 4.4BSD flags field.[13]

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.[14] ACLs are supported in VMS 4.0 and later.[15]

Solaris ACL support depends on the filesystem being used; older UFS filesystem supports POSIX.1e ACLs, while ZFS supports only NFSv4 ACLs.[16]

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

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.[18][_failed verification_]

Traditional POSIX permissions

[edit]

Traditionally, file permissions on a Unix-based file system is defined by POSIX.1-2017,[19]. 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 [umask](/wiki/Umask "Umask") command.

In a Unix-based file system, everything is a file, even directories and other special files.

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

The following permissions grant the corresponding operations on files and directories:

• For files: grants the ability to read the file’s contents (not its name or metadata, which are determined by the permissions of its parent directory).
• For directories: grants the ability to read the directory entry names of its contained files and directories, but not to access their metadata (inode) and therefore their content, which is determined by the directory execute permission.
• For files: grants the ability to modify the file contents.
• For directories: grants the ability to modify entries in the directory, which allows creating, deleting, and renaming its files or directories.
  • Doing so also requires the execute permission in order to access the metadata (inode) of all its containing files and directories. Therefore, without execute permission the write permission is effectively meaningless.
• For files: grants the ability to execute a file. This permission must be set for executable programs to allow running them.
  • Doing so also requires the read permission.
• For directories: grants the ability to read the metadata of its containing files and directories if their names are known, but not to read their names. A directory without execute permission effectively blocks reading and writing the content of its contained files and directories.
  • A directory with execute permission but without read permission effectively makes it a name guessing game to access the contents of its files and directories.

General access requirement inside directories

[edit]

Accessing the content of file or directory inside a directory requires;

1. Knowing its name which is discoverable if the parent directory read permission is set (or by guessing its name).
2. The parent directory execute permission to access the file or directory inode.
3. Its corresponding read, write or execute permissions.

Permission requirement summarry for file operations

[edit]

To read from a file you need:

• The file read permission.
• Execute permission on its parent directory .

To write to a file you need:

• The file write permission.
• Execute permission on its parent directory .

To execute a file you need:

• The file read and execute permission.
• Execute permission on its parent directory .

To know the name of the file you need:

• Read permission of its parent directory .

To add, remove, or rename a file you need:

• write, and execute permission on its parent directory.

Metadata of a file or directory typically includes inode id, file type, size, ownership (GUI and UID), and permission bits.

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

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

[edit]

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

• The set user ID, setuid, or SUID mode. Executing a file with this bit set results in a process with user ID set to the file's owning user. This enables users to be treated temporarily as root (or another user).
• The set group ID, setgid, or SGID permission. Executing a file with this bit set results in a process with 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 mode (also known as the Text mode). The classical behavior 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.

Permissions are commonly represented in symbolic or octal notation.

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

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

Examples:

• -rwxr-xr-x: initial - indicates a regular file, next three rwx indicate that user class has all permissions and group and others classes (both r-x) have only read and execute
• crw-rw-r--: initial c indicates a character special file, user and group classes (both rw-) have read and write permissions and others class (r--) has only read permission
• dr-x------: initial d indicates a directory, user class (r-x) has read and execute permissions and group and others classes (both ---) 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, x becomes s and - becomes S. For the sticky or text attribute x becomes t and - becomes T. 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 has setuid, setgid and sticky attributes set.

Some systems show 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

Permissions are often shown in octal notation; for example via the command stat -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 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 logic 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.[21][22]

• 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

1. ^ a b c The Compatible Time-Sharing System: A Programmer's Guide (PDF). The MIT Press. 1963.
2. ^ The Compatible Time-Sharing System: A Programmer's Guide (PDF) (Second ed.). The MIT Press. 1965. Section AD.2, p. 5.
3. ^ a b Multics Programmer's Manual Reference Guide (PDF). Honeywell. December 1975.
4. ^ a b TENEX Executive Manual (PDF). BBN. April 1973.
5. ^ DECsystem 10 Monitor Calls Manual (PDF). DEC. May 1974.
6. ^ Unix Programmer's Manual, System calls, Part 1 (PDF). November 3, 1971. SYS CHMOD (II).
7. ^ "Tarball of v3 man pages; see stat.2".
8. ^ "Tarball of v4 man pages; see stat.2".
9. ^ "File and Folder Permissions". Microsoft. 9 December 2009.
10. ^ "Native NFSv4 ACLs on Linux". Archived from the original on October 12, 2008. Retrieved May 4, 2010.
11. ^ "NFSv4_ACLs – FreeBSD Wiki".
12. ^ "FreeNAS 9.1.1 Users Guide" (PDF). 2013. Archived from the original (PDF) on September 24, 2015.
13. ^ Gite, Vivek (June 3, 2010). "Apple OS X: Write Protect File From Command Line".
14. ^ "OpenVMS documentation". Archived from the original on March 5, 2012. Retrieved June 6, 2009.
15. ^ "File Systems: Protection". CS322 Lecture Slides.
16. ^ "Oracle Solaris ZFS Administration Guide" (PDF). Sep 2010.
17. ^ "IBM Knowledge Center". Archived from the original on June 29, 2013.
18. ^ "HarmonyOS Distributed File System Development Guide". Substack. LivingInHarmony Blog. 13 March 2024. Retrieved 13 March 2024.
19. ^ "Definitions, 3.175 File Permission Bits". pubs.opengroup.org. 2018-07-22. Retrieved 2023-06-24.
20. ^ Hatch, Bri (April 24, 2003). "Linux File Permission Confusion pt 2". Hacking Linux Exposed. Retrieved July 6, 2011.
21. ^ 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.
22. ^ "Red Hat Enterprise Linux 7 System Administrator's Guide, 4.3.4 Creating Group Directories". Red Hat Customer Portal. Red Hat.

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