Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
tutorials:permissions [2011/04/30 13:18] – created clemenstutorials:permissions [2012/05/05 20:06] (current) – Minor formatting, $ID memnon
Line 3: Line 3:
 ===== Contents ===== ===== Contents =====
  
-  - [[#introduction|Introduction]] +  - [[#Introduction]] 
-  - [[#permissions|Permissions]] +  - [[#Permissions]] 
-    * [[#permissiontypes|Permission types]] +    * [[#Permission types]] 
-    * [[#userclasses|User classes]] +    * [[#User classes]] 
-    * [[#anexample|An example]] +    * [[#An example]] 
-    * [[#linksandpermissions|Links and permissions]] +    * [[#Links and permissions]] 
-  - [[#changing|Changing permissions…]] +  - [[#Changing permissions…]] 
-  - [[#explained|…explained]] +  - [[#…explained]] 
-  - [[#anotherway|…another way]] +  - [[#…another way]] 
-  - [[#flags|File Flags]]+  - [[#File Flags]]
  
-===== [[|Introduction]] =====+===== Introduction =====
  
 Unix was created to be a multi-user operating system. The intention was not for everybody to have full access to all files, but to allow file owners to specify which users should have what kind of access. Unix was created to be a multi-user operating system. The intention was not for everybody to have full access to all files, but to allow file owners to specify which users should have what kind of access.
  
-===== [[|Permissions]] =====+===== Permissions =====
  
 A Unix file system allows users to assign to files (including directories: "In Unix, Everything Is a File.") they own any combination of three permission types (**r**, **w**, **x**) to three classes of users (**u**, **g**, **o**). When a user requests access to a file, Unix first determines the requester's user class relative to the target file, then checks if the permission type requested has been assigned to that user class. A Unix file system allows users to assign to files (including directories: "In Unix, Everything Is a File.") they own any combination of three permission types (**r**, **w**, **x**) to three classes of users (**u**, **g**, **o**). When a user requests access to a file, Unix first determines the requester's user class relative to the target file, then checks if the permission type requested has been assigned to that user class.
  
-==== [[|Permission types]] ====+==== Permission types ====
  
 The effect of the three permission types varies depending on whether they apply to a file or a directory. The effect of the three permission types varies depending on whether they apply to a file or a directory.
Line 30: Line 30:
 ^ w | Change (**w**rite) file contents. | Add or remove files from directory.<sup>2</sup> | ^ w | Change (**w**rite) file contents. | Add or remove files from directory.<sup>2</sup> |
 ^ x | Shell will attempt to e**x**ecute file if file name entered by itself on command line. | Access (read or write) the directory<sup>3</sup> or any files in the directory or its subtree, or make the directory the user's working directory. | ^ x | Shell will attempt to e**x**ecute file if file name entered by itself on command line. | Access (read or write) the directory<sup>3</sup> or any files in the directory or its subtree, or make the directory the user's working directory. |
-**Notes:**     - File information can be obtained even without directory **r** permission if a file's full name is specified,    - **w** directory permission allows a user to delete a file from the directory, //even if the user does not have **w** (change contents) permission for the file itself//. The reverse is also possible: a user who lacks **w** directory permission may be able to modify the contents of a file in the directory but not delete it.    - Implementations vary on the permission required to list directory file names. SDF hosts (running NetBSD) will list directory files if the user has **r** permission for the directory. Other implementations require both **r** and **x** permissions to list directory files. |||+ **Notes:**      
 +  - File information can be obtained even without directory **r** permission if a file's full name is specified,     
 +  - **w** directory permission allows a user to delete a file from the directory, even if the user does not have **w** (change contents) permission for the file itself. The reverse is also possible: a user who lacks **w** directory permission may be able to modify the contents of a file in the directory but not delete it.     
 +  - Implementations vary on the permission required to list directory file names. SDF hosts (running NetBSD) will list directory files if the user has **r** permission for the directory. Other implementations require both **r** and **x** permissions to list directory files. 
  
 Unlike some other file systems, such as NTFS, neither **r** nor **w** directory permission have any influence on **r** or **w** permission for subdirectories or files anywhere in the directory's subtree. **r** or **w** permission is determined by what has been assigned to your user class for the directory in question without considering **r** and **w** permission for directories higher in the file system tree. Unlike some other file systems, such as NTFS, neither **r** nor **w** directory permission have any influence on **r** or **w** permission for subdirectories or files anywhere in the directory's subtree. **r** or **w** permission is determined by what has been assigned to your user class for the directory in question without considering **r** and **w** permission for directories higher in the file system tree.
Line 36: Line 39:
 However, directory **x** permission //does// affect permissions for subdirectories and files farther down the directory subtree. To access a file, a user must have **x** permission on every directory in the file's path. In other words, lack of **x** permission for a directory effectively prevents access to any files in the directory's subtree. However, directory **x** permission //does// affect permissions for subdirectories and files farther down the directory subtree. To access a file, a user must have **x** permission on every directory in the file's path. In other words, lack of **x** permission for a directory effectively prevents access to any files in the directory's subtree.
  
-==== [[|User classes]] ====+==== User classes ====
  
 For a given file, the Unix file system divides users into three classes: For a given file, the Unix file system divides users into three classes:
Line 44: Line 47:
 ^ g | //**G**roup//. Members of the user group to which the file has been assigned. | ^ g | //**G**roup//. Members of the user group to which the file has been assigned. |
 ^ o | //**O**thers//. Users not in either of the above classes. This is the user class that SDF's web server uses when a web browser requests a file from your web site.<sup>1</sup> | ^ o | //**O**thers//. Users not in either of the above classes. This is the user class that SDF's web server uses when a web browser requests a file from your web site.<sup>1</sup> |
-**Notes:**     - The use of CGI programs on a web site complicates the permission check. Access to the CGI program file itself is checked with user class **o**. Many web servers are configured so that file access requests from CGI programs are also checked with user class **o**. However, the SDF web server has been configured to execute CGI programs with the permissions of the owner of the program file (//you//, for CGI programs you have installed on your SDF web site). Therefore if your CGI program accesses files owned by you, permissions will be checked with user class **u**. Files not owned by you will be checked with user class **o**. ||+**Notes:**      
 +  - The use of CGI programs on a web site complicates the permission check. Access to the CGI program file itself is checked with user class **o**. Many web servers are configured so that file access requests from CGI programs are also checked with user class **o**. However, the SDF web server has been configured to execute CGI programs with the permissions of the owner of the program file (//you//, for CGI programs you have installed on your SDF web site). Therefore if your CGI program accesses files owned by you, permissions will be checked with user class **u**. Files not owned by you will be checked with user class **o**.
  
-==== [[|An example]] ====+==== An example ====
  
 File permission information can be obtained with the long listing option of the "ls" command: "ls -l" File permission information can be obtained with the long listing option of the "ls" command: "ls -l"
  
 +^ //a//        |     ^ //b//  ^ //c//  |                      |             |
 | "drwxr-xr-x" | "2" | "papa" | "arpa" | "512" | "Sep 29 01:02" | "arpastuff" | | "drwxr-xr-x" | "2" | "papa" | "arpa" | "512" | "Sep 29 01:02" | "arpastuff" |
 | "-rwxr-x---" | "1" | "papa" | "arpa" | "11402" | "Sep 29 01:02" | "hello" | | "-rwxr-x---" | "1" | "papa" | "arpa" | "11402" | "Sep 29 01:02" | "hello" |
 | "-rw-r-----" | "1" | "papa" | "arpa" | "13" | "Sep 29 01:02" | "hello.txt" | | "-rw-r-----" | "1" | "papa" | "arpa" | "13" | "Sep 29 01:02" | "hello.txt" |
-| //a// |  | //b// | //c// |  |  |  | 
  
 Field //a// is the //file mode//, a string of ten one-character flags that indicate the file's permissions and other information. The following is a list of mode flags in character order with a partial list of possible flag values for each: Field //a// is the //file mode//, a string of ten one-character flags that indicate the file's permissions and other information. The following is a list of mode flags in character order with a partial list of possible flag values for each:
  
   - File type. "d"directory"-"ordinary file   - File type. "d"directory"-"ordinary file
-  - **r** permission for file owner (user class **u**). "r"yes"-"no +  - **r** permission for file owner (user class **u**). "r"yes"-"no. 
-  - **w** permission for file owner (user class **u**). "w"yes"-"no +  - **w** permission for file owner (user class **u**). "w"yes"-"no. 
-  - **x** permission for file owner (user class **u**). "x"yes"-"no +  - **x** permission for file owner (user class **u**). "x"yes"-"no. 
-  - **r** permission for file user group (user class **g**). "r"yes"-"no +  - **r** permission for file user group (user class **g**). "r"yes"-"no. 
-  - **w** permission for file user group (user class **g**). "w"yes"-"no +  - **w** permission for file user group (user class **g**). "w"yes,"-"no. 
-  - **x** permission for file user group (user class **g**). "x"yes"-"no +  - **x** permission for file user group (user class **g**). "x"yes"-"no. 
-  - **r** permission for other users (user class **o**). "r"yes"-"no +  - **r** permission for other users (user class **o**). "r"yes"-"no. 
-  - **w** permission for other users (user class **o**). "w"yes"-"no +  - **w** permission for other users (user class **o**). "w"yes"-"no. 
-  - **x** permission for other users (user class **o**). "x"yes"-"no+  - **x** permission for other users (user class **o**). "x"yes"-"no.
  
 Field //b// is the user ID of the //file owner//. Field //c// is //user group// the file has been assigned to. Field //b// is the user ID of the //file owner//. Field //c// is //user group// the file has been assigned to.
Line 72: Line 76:
 So for the three files in the "ls" listing above: So for the three files in the "ls" listing above:
  
-Directory "arpastuff"User "papa" can list, add, and delete files in "arpastuff", access the directory's subtree, or make the directory his working directory. Users in group "arpa" and all other users can list files in the directory, access the directories subtree, or make the directory their working directory, but not add or delete files. File "hello"User "papa" can read or modify the contents of "hello" or execute it from the command line (presumably the file contents are an executable binary or a script). Users in group "arpa" may view or execute the file but not modify it. Other users may not access the file. File "hello.txt"User "papa" can read or modify the contents of "hello.txt". Users in group "arpa" may view the file. Other users may not access the file.+  * //Directory "arpastuff"// 
 +User "papa" can list, add, and delete files in "arpastuff", access the directory's subtree, or make the directory his working directory. Users in group "arpa" and all other users can list files in the directory, access the directories subtree, or make the directory their working directory, but not add or delete files. 
 +  * //File "hello"// 
 +User "papa" can read or modify the contents of "hello" or execute it from the command line (presumably the file contents are an executable binary or a script). Users in group "arpa" may view or execute the file but not modify it. Other users may not access the file.  
 +  * //File "hello.txt"// 
 +User "papa" can read or modify the contents of "hello.txt". Users in group "arpa" may view the file. Other users may not access the file.
  
-==== [[|Links and permissions]] ====+==== Links and permissions ====
  
 In general, the above discussion also applies to hard and symbolic file links. The files system automatically maintains links to keep the same effective permissions as the target file. (For symbolic links, the "ls" command displays a file mode with all permission types assigned for all user classes, but when file access is requested with the link, the permissions of the target file are applied.) In general, the above discussion also applies to hard and symbolic file links. The files system automatically maintains links to keep the same effective permissions as the target file. (For symbolic links, the "ls" command displays a file mode with all permission types assigned for all user classes, but when file access is requested with the link, the permissions of the target file are applied.)
Line 80: Line 89:
 However, it is possible for hard links to avoid directory **x** permission restrictions in some configurations. Suppose a user has access to a file "./d1/f1" to which there is a hard link outside directory "d1"'s subtree, "./h1". If the use loses **x** permission for "d1", he will not be able to access "./d1/f1", //but he will still be able to access the same file with his original permissions by using the hard link// "./h1". However, it is possible for hard links to avoid directory **x** permission restrictions in some configurations. Suppose a user has access to a file "./d1/f1" to which there is a hard link outside directory "d1"'s subtree, "./h1". If the use loses **x** permission for "d1", he will not be able to access "./d1/f1", //but he will still be able to access the same file with his original permissions by using the hard link// "./h1".
  
-===== [[|Changing permissions…]] =====+===== Changing permissions… =====
  
 Permissions are changed with the command "chmod": Permissions are changed with the command "chmod":
Line 92: Line 101:
 What does that number, 644, stand for? What does that number, 644, stand for?
  
-===== [[|…explained]] =====+===== …explained =====
  
 The //permission-mode// is a numeric representation of the nine file mode permission flags. As mentioned earlier, there are three permission types of and three user classes. Each digit represents the permission types assigned to a user class. The //permission-mode// is a numeric representation of the nine file mode permission flags. As mentioned earlier, there are three permission types of and three user classes. Each digit represents the permission types assigned to a user class.
Line 114: Line 123:
 Et voila! Et voila!
  
-===== [[|…another way]] =====+===== …another way =====
  
 "chmod" supports an alternate syntax for specifying permission modes that is more convenient for changing one or a few permissions at a time and is slightly easier to remember than the numeric mode coding above. "chmod" supports an alternate syntax for specifying permission modes that is more convenient for changing one or a few permissions at a time and is slightly easier to remember than the numeric mode coding above.
  
-//&lt;user-classes&gt;&lt;operation&gt;&lt;permission-types&gt;//[,//&lt;user-classes&gt;&lt;operation&gt;&lt;permission-types&gt;//]…+//<user-classes><operation><permission-types>//[,//<user-classes><operation><permission-types>//]…
  
-//user-classes//User class(es) for which permissions are to be changed. Specify with one-character class symbols "u", "g", "o", or "a" for all classes. May specify more than one class. //operation//One of the following: "+"Add permission types to user classes."-"Remove permission types from user classes."="Set permission types for user classes.//permission-types//Permission type(s) to be set or removed. Use one-character type symbols "r", "w", or "x". May specify more than one type.+===user-classes=== 
 +User class(es) for which permissions are to be changed. Specify with one-character class symbols "u", "g", "o", or "a" for all classes. May specify more than one class.  
 +===operation=== 
 +One of the following:  
 +  *"+" Add permission types to user classes. 
 +  *"-" Remove permission types from user classes. 
 +  *"=" Set permission types for user classes. 
 +===permission-types=== 
 +Permission type(s) to be set or removed. Use one-character type symbols "r", "w", or "x". May specify more than one type.
  
 Therefore the command: Therefore the command:
Line 134: Line 151:
 "chmod g+w index.html" "chmod g+w index.html"
  
-===== [[|File Flags]] =====+===== File Flags =====
  
 In addition to the file permissions we've already discussed, we also have file flags. File flags add additional security and control over files, but not directories. File flags are altered using the chflags(1) utility. In addition to the file permissions we've already discussed, we also have file flags. File flags add additional security and control over files, but not directories. File flags are altered using the chflags(1) utility.
Line 143: Line 160:
  
 "chflags nouunlnk foo" "chflags nouunlnk foo"
 +
 +$Id: permissions.html,v 1.8 2007/10/02 11:22:28 papa Exp $