File system permissions 1347955 224565392 2008-07-09T13:05:59Z Wwood 1602135 /* User private group */ 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. ==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] [[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. [[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. [[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. [[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?--> ==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). When a new file is created on a Unix-like system, its permissions are determined from the [[umask]] of the process that created it. ===Classes=== On Unix [[file system]]s, every [[Computer file|file]] and [[directory (file systems)|directory]] is ''owned'' by a specific user. The owner of an object comprises its ''user class''. Permissions assigned to the user class only apply to that specific user. A file or directory is also assigned a group, which comprises its ''group class.'' Permissions assigned to the group class only apply to members of that group (other than the owner). 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 otherwise represented by the other two classes comprise a file's ''others class''. The ''effective permissions'' that have applied to a specific user in relation to a file are determined in logical precedence. For example, the user who owns the file will have the effective permissions given to the user class regardless of those assigned to the group or others class. ===Basic Permissions=== There are three specific permissions on [[Unix-like]] systems that apply to each class: *The ''read'' permission, which 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, including file type, size, ownership, permissions, etc.) *The ''write'' permission, which grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory. This includes creating files, deleting files, and renaming files. *The ''execute'' permission, which grants the ability to execute a file. This permission must be set for executable binaries in order to allow the operating system to run them. When set for a directory, this permission grants the ability to traverse its tree in order to access files or subdirectories, but not see files inside the directory (unless ''read'' is set). The effect of setting the permissions on a directory (rather than a file) is "one of the most frequently misunderstood file permission issues" (Hatch 2003). When a permission is not set, the rights it would grant are denied. Unlike [[Access control list|ACL]]-based systems, permissions on a Unix-like system are not ''inherited''. Files created within a directory will not necessarily have the same permissions as that directory. The permissions to be assigned are determined using [[umask]]s. ===Additional Permissions=== [[Unix-like]] systems typically employ three additional permissions or modes. These special permissions are set for a file or directory overall, not by a class. *The ''[[Setuid|set user ID]]'', ''setuid'', or SUID permission. When a file for which this permission has been set is executed, the resulting process will assume the effective [[User identifier (Unix)|user ID]] given to the user class. *The ''[[Setgid|set group ID]]'', ''setgid'', or SGID permission. When a file for which this permission has been set 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 the 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.) *The ''[[Sticky bit|sticky]]'' permission. The typical behaviour of the sticky bit on executable files encourages the [[Kernel (computer science)|kernel]] to retain the resulting process image beyond termination. 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 permissions are also referred to as ''setuid bit'', ''setgid bit'', and ''sticky bit'' respectively, due to the fact that they each occupy only one bit. ==Notation of traditional Unix permissions== ===Symbolic notation=== There are many ways by which Unix permission schemes are represented. The most common form is '''symbolic notation'''. This scheme represents permissions as a series of 10 characters. {|class="wikitable" style="float: right" !colspan="2" style="text-align: left"|First Character |- |style="text-align: center"|<tt>-</tt>||a regular file |- |style="text-align: center"|<tt>d</tt>||a [[directory (file systems)|directory]] |- |style="text-align: center"|<tt>l</tt>|| a symbolic link |- !colspan="2" style="text-align: left"|Three groups of three |- |style="text-align: center"|first||what the owner can do |- |style="text-align: center"|second||what the group members can do |- |style="text-align: center"|third||what other users can do |- !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]]. |} 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 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. Each of the three characters represent the read, write, and execute permissions respectively: *<tt>r</tt> if the read bit is set, <tt>-</tt> if it is not. *<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=== The three additional permissions are indicated by changing one of the three "execute" characters as shown in the following table: {|class="wikitable" !style="text-align:left"|Permission !style="text-align:left"|Class !style="width: 6em"|Executable<sup>1</sup> !style="width: 6em"|Non-executable<sup>2</sup> |- |[[Setuid|Set User ID]] (<tt>setuid</tt>) |User |style="text-align: center"|<tt>s</tt> |style="text-align: center"|<tt>S</tt> |- |[[Setgid|Set Group ID]] (<tt>setgid</tt>) |Group |style="text-align: center"|<tt>s</tt> |style="text-align: center"|<tt>S</tt> |- |[[Sticky bit]] |Others |style="text-align: center"|<tt>t</tt> |style="text-align: center"|<tt>T</tt> |- |} <ol style="font-size: 0.75em"> <li>The character that will be used to indicate that the execute bit is also set.</li> <li>The character that will be used when the execute bit is not set.</li> </ol> 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. ===Octal notation=== Another common method for representing Unix permissions is ''[[octal]] notation''. Octal notation consists of a three- or four-digit [[Number base#Bases_used|base]]-8 value. With three-digit octal notation, each numeral represents a different component of the permission set: user class, group class, and "others" class respectively. 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: *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. These are the examples from the [[#Symbolic_notation|Symbolic notation]] section given in octal notation: *<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. *<tt>"-r-x------"</tt> would be represented as <tt>500</tt> in three-digit octal. Here is a summary of the meanings for individual octal digit values: 1 --x execute 2 -w- write 3 -wx write and execute 4 r-- read 5 r-x read and execute 6 rw- read and write 7 rwx read, write and execute Octal digit values can be added together to make Symbolic Notations:<br /> (4=r)+(1=x) == (5=r-x)<br /> (4=r)+(2=w) == (6=rw-)<br /> (4=r)+(2=w)+(1=x) == (7=rwx)<br /> 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 ===Octal notation and additional permissions=== There is also a ''four-digit'' form of octal 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: *The [[setuid]] bit adds 4 to the total, *The [[setgid]] bit adds 2 to the total, and *The [[sticky bit]] adds 1 to the total. The example from the ''Symbolic notation and additional permissions'' section, <tt>"-rwsr-Sr-x"</tt> would be represented as <tt>6745</tt> in four-digit octal. In addition, the examples in the previous section (<tt>755</tt>, <tt>664</tt>, and <tt>500</tt>) would be represented as <tt>0755</tt>, <tt>0664</tt>, and <tt>0500</tt> respectively in four-digit octal notation. == User private group == Some system administrators create a new group -- a "user private group" -- for each new user. The "user private group" scheme makes it easier<ref>http://www.oreillynet.com/onlamp/blog/2006/09/using_user_private_groups.html</ref><ref>http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-users-groups-private-groups.html</ref><ref>http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/s1-users-groups-private-groups.html</ref> 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== *[[chmod]], the command used to set permissions on Unix-like systems *[[Access control list]] *[[POSIX]] *[[File system]] *[[User identifier (Unix)]] *[[Group identifier (Unix)]] *[[chattr]] *[[lsattr]] ==External links== * [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 [[Category:Computer file systems]] [[Category:Computer security procedures]] [[de:Dateiberechtigung]] [[el:Άδειες συστήματος αρχείων]] [[es:Permisos de acceso a archivos]] [[fr:Permissions Unix]] [[ja:ファイルパーミッション]] [[pl:Prawa dostępu]]