File-system permissions: Difference between revisions
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
|||
(453 intermediate revisions by more than 100 users not shown) | |||
Line 1: | Line 1: | ||
{{Use American English|date=January 2019}} |
|||
Most modern [[file system]]s have methods of administering '''permissions''' or '''access rights''' to specific [[user (computing)|users]] and groups of users. These systems control the ability of the users affected to view or make changes to the contents of the file system. |
|||
{{Short description|Allowed actions in file systems}} |
|||
Most [[file system]]s include attributes of files and directories that control the ability of users to read, change, navigate, and [[Execution (computing)|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 user interface|permission-driven]]. |
|||
==Differences between operating systems== |
|||
[[Unix-like]] and otherwise [[POSIX]]-compliant systems, including [[Linux]]-based systems and all [[Mac OS X]] versions, have a simple system for managing individual file permissions, which in this article are called "traditional Unix permissions". POSIX also specifies a system of [[access control list]]s that are now supported for many Unix and Linux file systems. [http://www.vanemery.com/Linux/ACL/linux-acl.html] |
|||
Two types of permissions are widely available: [[POSIX]] file system permissions and [[access-control list]]s (ACLs) which are capable of more specific control. |
|||
[[DOS]] variants (including the Microsoft products [[MS-DOS]], [[Windows 95]], [[Windows 98]], and [[Windows Me]]) do not have permissions. There is a "[[read-only]]" attribute that can be set or unset on a file by any user or program. |
|||
==File system variations== |
|||
[[OpenVMS|VMS and OpenVMS]] as well as [[Windows NT|Microsoft Windows NT]] and its derivatives (including [[Windows 2000]] and [[Windows XP]]), use [[access control list]]s (ACLs) to administer a more complex and varied set of permissions. |
|||
The original [[File Allocation Table]] file system has a per-file all-user read-only attribute. |
|||
[[NTFS]] implemented in [[Windows NT|Microsoft Windows NT]] and its derivatives, use ACLs<ref>{{cite web |url=https://technet.microsoft.com/en-us/library/bb727008.aspx |title=File and Folder Permissions |publisher=Microsoft}}</ref> to provide a complex set of permissions. |
|||
[[Mac_OS_history | Classic Mac OSes]] are similar to DOS variants and DOS based Windows: they do not support permissions, but only a "Protected" file attribute. |
|||
[[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.<ref>{{cite web |url=http://h71000.www7.hp.com/doc/731final/6489/6489pro_025.html#int_prot_code |title=OpenVMS documentation |access-date=2009-06-06 |archive-url=https://web.archive.org/web/20120305181412/http://h71000.www7.hp.com/doc/731final/6489/6489pro_025.html#int_prot_code |archive-date=2012-03-05 |url-status=dead}}</ref> |
|||
[[Mac OS X]], beginning with version 10.4 ("Tiger"), supports the use of complex [[access control list]]s (ACLs). It also supports "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. |
|||
<!-- is the kind of ACL used in Mac OS 10.4 the same as, or something different from, the kind of ACL specified by POSIX ? --> |
|||
<!--Where are IBM main and mini OSs?--> |
|||
[[Hierarchical File System (Apple)|HFS]], and its successor [[HFS Plus|HFS+]], implemented in the [[Classic Mac OS]] operating systems, do not support permissions. |
|||
==Traditional Unix permissions== |
|||
Permissions on [[Unix-like]] systems are managed in three distinct ''classes''. These classes are known as ''user'', ''group'', and ''others''. In effect, Unix permissions are a simplified form of [[access control list]]s (ACLs). |
|||
[[macOS]] uses POSIX-compliant permissions. 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. |
|||
When a new file is created on a Unix-like system, its permissions are determined from the [[umask]] of the process that created it. |
|||
[[Solaris (operating system)|Solaris]] ACL support depends on the filesystem being used; older [[Unix File System|UFS]] filesystem supports POSIX.1e ACLs, while [[ZFS]] supports only NFSv4 ACLs.<ref>{{cite web |url=http://docs.oracle.com/cd/E19253-01/819-5461/819-5461.pdf |title=Oracle Solaris ZFS Administration Guide |date=Sep 2010}}</ref> |
|||
[[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<ref>{{cite web |url=http://www.suse.de/~agruen/nfs4acl/ |title=Native NFSv4 ACLs on Linux |access-date=2010-05-04 |url-status=dead |archive-url=https://web.archive.org/web/20081012054117/http://www.suse.de/~agruen/nfs4acl/ |archive-date=2008-10-12 }}</ref> and ext4 filesystems. |
|||
[[FreeBSD]] supports POSIX.1e ACLs on UFS, and NFSv4 ACLs on UFS and ZFS.<ref>{{cite web |url=http://wiki.freebsd.org/NFSv4_ACLs |title=NFSv4_ACLs – FreeBSD Wiki }}</ref><ref>{{cite web |url=http://www.freenas.org/images/resources/freenas9.1.1/freenas9.1.1_guide.pdf |title=FreeNAS 9.1.1 Users Guide |date=2013}}</ref> |
|||
[[IBM z/OS]] implements file security using RACF (Resource Access Control Facility)<ref>{{cite web |url=http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.e0ze100%2Fracf.htm |title=IBM Knowledge Center }}</ref> |
|||
[[AmigaDOS|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]] and also [[Linux|Linux-based]] [[EulerOS|openEuler]] server OS natively uses it's Harmony Distributed File System (HMDFS) that supports [[Access token manager]] permission management with exception to openEuler.<ref>{{cite web |title=HarmonyOS Distributed File System Development Guide |url=https://livinginharmony.substack.com/p/harmonyos-distributed-file-system |website=Substack |publisher=LivingInHarmony Blog |access-date=13 March 2024}}</ref> |
|||
==POSIX permissions== |
|||
{{see also|Unix file types#Representations}} |
|||
Permissions on [[Unix-like]] file systems are defined in the POSIX.1-2017 standard,<ref>{{Cite web |date=2018-07-22 |title=Definitions, 3.175 File Permission Bits |url=https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_175 |access-date=2023-06-24 |website=pubs.opengroup.org}}</ref> 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=== |
===Classes=== |
||
[[Computer file|Files]] and [[directory (file systems)|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 identifier|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. |
|||
While a particular file can be assigned to only one group, a particular user can be a member of any number of groups, and a group can include any number of users. The "groups" command lists all the groups that include a user; the "members" command lists all the users that are the member of a particular group (Stutz 2004). |
|||
The system administrator uses "addgroup" to add a user to a group. |
|||
Users who are not |
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'' |
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 |
* 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 |
* 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 |
* 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 |
The effect of setting the permissions on a directory, rather than a file, is "one of the most frequently misunderstood file permission issues".<ref>Hatch, Bri. [http://www.hackinglinuxexposed.com/articles/20030424.html "Linux File Permission Confusion pt 2"], "Hacking Linux Exposed", April 24, 2003, accessed July 6, 2011.</ref> |
||
When a permission is not set, the rights |
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=== |
|||
===Additional Permissions=== |
|||
[[Unix-like]] systems typically employ three additional permissions or modes. These special |
[[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 ''[[Setuid|set user ID]]'', ''setuid'', or SUID |
* The ''[[Setuid|set user ID]]'', ''setuid'', or SUID mode. When a file with setuid is executed, the resulting process will assume the effective [[User identifier (Unix)|user ID]] given to the owner class. This enables users to be treated temporarily as root (or another user). |
||
*The ''[[Setgid|set group ID]]'', ''setgid'', or SGID permission. |
* The ''[[Setgid|set group ID]]'', ''setgid'', or SGID permission. When a file with ''setgid'' is executed, the resulting process will assume the [[Group identifier (Unix)|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 bit|sticky]]'' |
* The ''[[Sticky bit|sticky]]'' mode (also known as the ''Text'' mode). The classical behaviour of the sticky bit on executable files has been to encourage the [[Kernel (operating system)|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 |
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== |
==Notation of traditional Unix permissions== |
||
===Symbolic notation=== |
===Symbolic notation=== |
||
Unix permissions are represented either in symbolic notation or in octal notation. |
|||
The most common form, as used by the command <code>ls -l</code>, is '''symbolic notation'''. |
|||
{| style="margin-right:0; margin-left: 1em" class="wikitable floatright" |
|||
{|class="wikitable" style="float: right" |
|||
|+ |
|||
!colspan="2" style="text-align: left"|First Character |
|||
|- |
|- |
||
!colspan="2" style="text-align: left"|Three permission triads |
|||
|- |
|- |
||
|style="text-align: |
|style="text-align: right; vertical-align: text-top;"|first triad||what the owner can do |
||
|- |
|- |
||
|style="text-align: |
|style="text-align: right; vertical-align: text-top;"|second triad||what the group members can do |
||
|- |
|- |
||
|style="text-align: right; vertical-align: text-top;"|third triad||what other users can do |
|||
|- |
|- |
||
!colspan="2" style="text-align: left"|Each triad |
|||
|- |
|- |
||
|style="text-align: |
|style="text-align: right; vertical-align: text-top;"|first character||<code>r</code>: readable |
||
|- |
|- |
||
|style="text-align: |
|style="text-align: right; vertical-align: text-top;"|second character||<code>w</code>: writable |
||
|- |
|- |
||
|style="text-align: right; vertical-align: text-top;"|third character||<code>x</code>: executable<br /><code>s</code> or <code>t</code>: [[setuid]]/[[setgid]] or [[sticky bit|sticky]] (also executable)<br /><code>S</code> or <code>T</code>: setuid/setgid or sticky (not executable) |
|||
!colspan="2" style="text-align: left"|The triplet |
|||
<!-- |
|||
|style="text-align: center"|first||<tt>r</tt>: readable. |
|||
|- |
|||
|style="text-align: center"|second||<tt>w</tt>: writable. |
|||
|- |
|||
|rowspan="2" style="text-align: center"|third||<tt>x</tt>: executable. |
|||
|- |
|- |
||
|other: see [[#Symbolic notation and additional permission|below]]. |
|other: see [[#Symbolic notation and additional permission|below]]. |
||
--> |
|||
|} |
|} |
||
The first character of the <code>ls</code> display indicates the [[Unix file types|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. |
|||
The first character indicates the [[Unix file types|file type]]: |
|||
*<tt>-</tt> denotes a regular file |
|||
*<tt>d</tt> denotes a [[directory (file systems)|directory]] |
|||
*<tt>b</tt> denotes a [[block special file]] |
|||
*<tt>c</tt> denotes a [[character special file]] |
|||
*<tt>l</tt> denotes a [[symbolic link]] |
|||
*<tt>p</tt> denotes a [[named pipe]] |
|||
*<tt>s</tt> denotes a [[Unix domain socket|domain socket]] |
|||
Each of the three characters represent the read, write, and execute permissions: |
|||
Each class of permissions is represented by three characters. The first set of characters represents the user class. The second set represents the group class. The third and final set of three characters represents the others class. |
|||
* <code>r</code> if reading is permitted, <code>-</code> if it is not. |
|||
* <code>w</code> if writing is permitted, <code>-</code> if it is not. |
|||
* <code>x</code> if execution is permitted, <code>-</code> if it is not. |
|||
<!-- |
|||
* The <code>x</code> will be an <code>s</code> if the setuid or setgid bit is also set, and in the third, it will be a <code>t</code> if the [[sticky bit]] is set. If these are set but the execute bit is not, the letter will be in uppercase. |
|||
--> |
|||
The following are some examples of symbolic notation: |
|||
* <code>-rwxr-xr-x</code>: a regular file whose user class has full permissions and whose group and others classes have only the read and execute permissions. |
|||
* <code>crw-rw-r--</code>: a character special file whose user and group classes have the read and write permissions and whose others class has only the read permission. |
|||
* <code>dr-x------</code>: 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 <code>ls -l</code> display represent additional permission features: |
|||
Each of the three characters represent the read, write, and execute permissions respectively: |
|||
* + (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 <code>ls -Z</code>. |
|||
*<tt>r</tt> if the read bit is set, <tt>-</tt> if it is not. |
|||
* @ suffix indicates [[extended file attributes]] are present. |
|||
*<tt>w</tt> if the write bit is set, <tt>-</tt> if it is not. |
|||
<!-- |
|||
*<tt>x</tt> if the execute bit is set, <tt>-</tt> if it is not. |
|||
* The <tt>x</tt> will be an <tt>s</tt> if the setuid or setgid bit is also set, and in the third, it will be a <tt>t</tt> if the [[sticky bit]] is set. If these are set but the execute bit is not, the letter will be in uppercase. |
|||
The following are some examples of symbolic notation: |
|||
*<code>-rwxr-xr-x</code> for a regular file whose user class has full permissions and whose group and others classes have only the read and execute permissions. |
|||
*<code>crw-rw-r--</code> for a character special file whose user and group classes have the read and write permissions and whose others class has only the read permission. |
|||
*<code>dr-x------</code> for a directory whose user class has read and execute permissions and whose group and others classes have no permissions. |
|||
===Symbolic notation and additional permission=== |
===Symbolic notation and additional permission=== |
||
Line 111: | Line 119: | ||
!style="width: 6em"|Non-executable<sup>2</sup> |
!style="width: 6em"|Non-executable<sup>2</sup> |
||
|- |
|- |
||
|[[Setuid|Set User ID]] (< |
|[[Setuid|Set User ID]] (<code>setuid</code>) |
||
|User |
|User |
||
|style="text-align: center"|< |
|style="text-align: center"|<code>s</code> |
||
|style="text-align: center"|< |
|style="text-align: center"|<code>S</code> |
||
|- |
|- |
||
|[[Setgid|Set Group ID]] (< |
|[[Setgid|Set Group ID]] (<code>setgid</code>) |
||
|Group |
|Group |
||
|style="text-align: center"|< |
|style="text-align: center"|<code>s</code> |
||
|style="text-align: center"|< |
|style="text-align: center"|<code>S</code> |
||
|- |
|- |
||
|[[Sticky bit]] |
|[[Sticky bit]] |
||
|Others |
|Others |
||
|style="text-align: center"|< |
|style="text-align: center"|<code>t</code> |
||
|style="text-align: center"|< |
|style="text-align: center"|<code>T</code> |
||
|- |
|||
|} |
|} |
||
<ol style="font-size: 0.75em"> |
<ol style="font-size: 0.75em"> |
||
Line 132: | Line 139: | ||
</ol> |
</ol> |
||
--> |
|||
Here is an example: |
|||
To represent the ''[[setuid]]'', ''[[setgid]]'' and ''[[sticky bit|sticky or text]]'' attributes, the executable character (<code>x</code> or <code>-</code>) 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 <code>x</code> becomes <code>s</code> and the <code>-</code> becomes <code>S</code>. For the sticky or text attribute, in the third triad, the <code>x</code> becomes <code>t</code> and the <code>-</code> becomes <code>T</code>. Here is an example: |
|||
*<tt>"-rwsr-Sr-x"</tt> for 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]]'' and ''[[setgid]]'' permissions set. |
|||
* <code>-rwsr-Sr-t</code>: 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 bit|sticky]]'' attributes set. |
|||
=== |
===Numeric notation=== |
||
Another |
Another method for representing Unix permissions is an [[octal]] (base-8) notation as shown by <code>stat -c %a</code>. 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|setuid bit]]'', the ''[[Setgid|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: |
|||
With three-digit octal notation, each numeral represents a different component of the permission set: user class, group class, and "others" class respectively. |
|||
* 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|symbolic notation]] section given in octal notation: |
|||
Each of these digits is the sum of its component bits (see also [[Binary numeral system]]). As a result, specific bits add to the sum as it is represented by a numeral: |
|||
{| class="wikitable" style="text-align: center;" |
|||
*The read bit adds 4 to its total (in binary 100), |
|||
|- |
|||
*The write bit adds 2 to its total (in binary 010), and |
|||
! Symbolic<br> notation !! Numeric<br> notation !! English |
|||
*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. |
|||
| style="text-align: center;" | <code>----------</code> || 0000 || style="text-align: left" | no permissions |
|||
|- |
|||
These are the examples from the [[#Symbolic_notation|Symbolic notation]] section given in octal notation: |
|||
| style="text-align: center;" | <code>-rwx------</code> ||0700|| style="text-align: left" | read, write, & execute only for owner |
|||
*<tt>"-rwxr-xr-x"</tt> would be represented as <tt>755</tt> in three-digit octal. |
|||
|- |
|||
*<tt>"-rw-rw-r--"</tt> would be represented as <tt>664</tt> in three-digit octal. |
|||
| style="text-align: center;" | <code>-rwxrwx---</code> || 0770 || style="text-align: left" | read, write, & execute for owner and group |
|||
*<tt>"-r-x------"</tt> would be represented as <tt>500</tt> in three-digit octal. |
|||
|- |
|||
| style="text-align: center;" | <code>-rwxrwxrwx</code> || 0777 || style="text-align: left" | read, write, & execute for owner, group and others |
|||
|- |
|||
| style="text-align: center;" | <code>---x--x--x</code> || 0111 || style="text-align: left" | execute |
|||
|- |
|||
| style="text-align: center;" | <code>--w--w--w-</code> || 0222 || style="text-align: left" | write |
|||
|- |
|||
| style="text-align: center;" | <code>--wx-wx-wx</code> || 0333 || style="text-align: left" | write & execute |
|||
|- |
|||
| style="text-align: center;" | <code>-r--r--r--</code> || 0444 || style="text-align: left" | read |
|||
|- |
|||
| style="text-align: center;" | <code>-r-xr-xr-x</code> || 0555 || style="text-align: left" | read & execute |
|||
|- |
|||
| style="text-align: center;" | <code>-rw-rw-rw-</code> || 0666 || style="text-align: left" | read & write |
|||
|- |
|||
| style="text-align: center;" | <code>-rwxr-----</code> || 0740 || style="text-align: left" | owner can read, write, & execute; group can only read; others have no permissions |
|||
|- |
|||
|} |
|||
<!-- |
|||
Here is a |
Here is a list of the meanings for individual octal digit values: |
||
0 --- no permission |
|||
1 --x execute |
|||
2 -w- write |
|||
3 -wx write and execute |
3 -wx write and execute |
||
4 r-- read |
4 r-- read |
||
5 r-x read and execute |
5 r-x read and execute |
||
6 rw- read and write |
6 rw- read and write |
||
7 rwx read, write and execute |
7 rwx read, write, and execute |
||
Here some example showing which digits affect permissions for user, group, and other: |
|||
Octal digit values can be added together to make Symbolic Notations:<br /> |
|||
* 754 = <code>"-rwxr-xr--"</code> = rwx for owner, r-x for group, r-- for other |
|||
(4=r)+(1=x) == (5=r-x)<br /> |
|||
* 124 = <code>"---x-w-r--"</code> = x for owner, w for group, r for other |
|||
(4=r)+(2=w) == (6=rw-)<br /> |
|||
(4=r)+(2=w)+(1=x) == (7=rwx)<br /> |
|||
no permissions at all! |
|||
Here is a summary showing which octal digits affect permissions for user, group, and other: |
|||
*UGO = User, Group, Other |
|||
*777 = <tt>"-rwxrwxrwx"</tt> = rwx for all |
|||
*754 = <tt>"-rwxr-xr--"</tt> = rwx for owner, r-x for group, r-- for other |
|||
*124 = <tt>"---x-w-r--"</tt> = x for owner, w for group, r for other |
|||
=== |
===Numeric notation and additional permissions=== |
||
There is also a ''four-digit'' form of |
There is also a ''four-digit'' form of numeric notation. In this scheme, the standard three digits described above become the last three digits. The first digit represents the additional permissions. On some systems, this first digit cannot be omitted; it is therefore common to use all four digits (where the first digit is zero). |
||
This first digit is also the sum of component bits: |
This first digit is also the sum of component bits: |
||
*The |
* The setuid bit adds 4 to the total, |
||
*The |
* The setgid bit adds 2 to the total, and |
||
*The |
* The sticky bit adds 1 to the total. |
||
The example from the ''Symbolic notation and additional permissions'' section, < |
The example from the ''Symbolic notation and additional permissions'' section, <code>"-rwsr-Sr-x"</code> would be represented as <code>6745</code> in four-digit octal. In addition, the examples in the previous section (<code>755</code>, <code>664</code>, and <code>500</code>) would be represented as <code>0755</code>, <code>0664</code>, and <code>0500</code> respectively in four-digit octal notation. |
||
--> |
|||
== |
==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.<ref>{{cite web |last1=Epstein |first1=Brian |title=The How and Why of User Private Groups in Unix |url=https://security.ias.edu/how-and-why-user-private-groups-unix |website=security.ias.edu |publisher=Institute for Advanced Study Network Security |access-date=5 August 2014 |archive-date=8 August 2014 |archive-url=https://web.archive.org/web/20140808054151/https://security.ias.edu/how-and-why-user-private-groups-unix |url-status=dead }}</ref><ref>{{cite web |title=Red Hat Enterprise Linux 7 System Administrator's Guide, 4.3.4 Creating Group Directories |url=https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-managing_users_and_groups#s2-users-tools-groups-directories |website=Red Hat Customer Portal |publisher=Red Hat}}</ref> |
|||
Some system administrators create a new group -- a "user private group" -- for each new user. |
|||
The "user private group" scheme makes it easier |
|||
[http://www.oreillynet.com/onlamp/blog/2006/09/using_user_private_groups.html] |
|||
[http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-users-groups-private-groups.html] |
|||
[http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/s1-users-groups-private-groups.html] |
|||
to set up a directory dedicated to each project of that group. |
|||
Only members of that group can create new files in that directory, and everyone in a group (and only the people in that group) can edit files in that directory. |
|||
==See also== |
==See also== |
||
* [[chattr]] or chflags: change attributes or flags including those which restrict access. |
|||
*[[chmod]], the command used to set permissions on Unix-like systems |
|||
* [[chmod]]: change mode (permissions) on Unix-like file systems |
|||
*[[Access control list]] |
|||
* [[chattr#lsattr description|lsattr]] list attributes |
|||
*[[POSIX]] |
|||
* [[Comparison of file systems#Metadata|Comparison of file systems § Metadata]] |
|||
*[[File system]] |
|||
*[[ |
* [[Group identifier (Unix)]] |
||
* [[POSIX]] |
|||
*[[Group identifier (Unix)]] |
|||
*[[ |
* [[umask]] |
||
* [[User identifier (Unix)]] |
|||
*[[lsattr]] |
|||
==References== |
|||
{{Reflist}} |
|||
==External links== |
==External links== |
||
* [https://web.archive.org/web/20170711093952/http://www.dsl.org/cookbook/cookbook_9.html The Linux Cookbook: Groups and How to Work in Them] by Michael Stutz 2004 |
|||
* [http://manuals.info.apple.com/en/File_Services_v10.4.pdf Apple Mac OS X Server version 10.4+ ''File Services Administration'' Manual (see pages 16-26)] |
|||
* [http://www.hackinglinuxexposed.com/articles/20030417.html "Linux File Permission Confusion"] by Brian Hatch 2003. |
|||
* [http://www.hackinglinuxexposed.com/articles/20030424.html "Linux File Permission Confusion pt 2"] by Brian Hatch 2003. |
|||
* [http://dsl.org/cookbook/cookbook_9.html The Linux Cookbook: Groups and How to Work in Them] by Michael Stutz 2004 |
|||
{{Computer files}} |
|||
{{File systems}} |
|||
[[Category:Computer security procedures]] |
|||
{{DEFAULTSORT:Filesystem permissions}} |
|||
[[de:Dateiberechtigung]] |
|||
[[Category:File system permissions| ]] |
|||
[[el:Άδειες συστήματος αρχείων]] |
|||
[[es:Permisos de acceso a archivos]] |
|||
[[fr:Permissions Unix]] |
|||
[[ja:ファイルパーミッション]] |
|||
[[pl:Prawa dostępu]] |
Revision as of 14:16, 11 April 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.
Two types of permissions are widely available: POSIX file system permissions and access-control lists (ACLs) which are capable of more specific control.
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+, implemented in the Classic Mac OS operating systems, do not support permissions.
macOS uses POSIX-compliant permissions. 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]
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 and also Linux-based openEuler server OS natively uses it's Harmony Distributed File System (HMDFS) that supports Access token manager permission management with exception to openEuler.[8]
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 : executables 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]
See also
- chattr or chflags: change attributes or flags including those which restrict access.
- chmod: change mode (permissions) on Unix-like file systems
- lsattr list attributes
- Comparison of file systems § Metadata
- Group identifier (Unix)
- POSIX
- umask
- User identifier (Unix)
References
- ^ "File and Folder Permissions". Microsoft.
- ^ "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. 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