Differences

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

--- permissions [2021/03/09 19:48] – [An example] hc9
+++ permissions [2024/09/06 06:17] (current) – no” hc9
@@ Line 1: / Line 1: @@
+====== Permissions ======
+===== 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.
+===== 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.
+==== Permission types ====
+The effect of the three permission types varies depending on whether they apply to a file or a directory.
+^ Type ^ On file ^ On directory ^
+^ r | Read file contents. | List name, size, modification date, etc. of files in directory.<sup>1</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. |
+| **Notes:** <sup>1</sup> File information can be obtained even without directory **r** permission if a file's full name is specified, <sup>2</sup> **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. <sup>3</sup> 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.
+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 ====
+For a given file, the Unix file system divides users into three classes:
+^ Class ^ Users ^
+^ u | //**U**ser//. The current owner of the file. |
+^ 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> |
+| **Notes:** <sup>1</sup> 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 ====
+File permission information can be obtained with the long listing option of the ''ls'' command: ''ls -l''
+| ''drwxr-xr-x'' | ''2'' | ''papa'' | ''arpa'' | ''512'' | ''Sep 29 01:02'' | ''arpastuff'' |
+| ''-rwxr-x---'' | ''1'' | ''papa'' | ''arpa'' | ''11402'' | ''Sep 29 01:02'' | ''hello'' |
+| ''-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:
+|1|File type.|
+| |''d''|directory|
+| | ''-''|ordinary file|
+|2|**r** permission for file owner (user class **u**).|
+| |''r''|yes|
+| | ''-''|no|
+|3|**w** permission for file owner (user class **u**).|
+| |''w''|yes|
+| | ''-''|no|
+|4|**x** permission for file owner (user class **u**).|
+| |''x''|yes|
+| | ''-''|no|
+|5|**r** permission for file user group (user class **g**).|
+| |''r''|yes|
+| | ''-''|no|
+|6|**w** permission for file user group (user class **g**).|
+| |''w''|yes|
+| | ''-''|no|
+|7|**x** permission for file user group (user class **g**).|
+| |''x''|yes|
+| | ''-''|no|
+|8|**r** permission for other users (user class **o**).|
+| |''r''|yes|
+| | ''-''|no|
+|9|**w** permission for other users (user class **o**).|
+| |''w''|yes|
+| | ''-''|no|
+|10|**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.
+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.
+==== 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.)
+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… =====
+Permissions are changed with the command ''chmod'':
+''chmod //permission-mode// //file-name//''
+Let's take a look at this example,
+''chmod 644 index.html''
+What does that number, 644, stand for?
+===== …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.
+^ User class: ^ u ^ g ^ o ^
+^ Permission code: | 6 | 4 | 4 |
+The permission code for each use class is calculated by summing the values corresponding to the permission types assigned to the user class: 4 for **r** permission , 2 for **w** permission, 1 for **x** permission.
+In the above example, I want file ''index.html'' to be readable by all users but writable by only me. Therefore permission codes would be as follows:
+^ User class ^ Permission types ^ Permission code ^
+^ u (myself) | **r** (4), **w** (2) | 4 + 2 = **6** |
+^ g (group) | **r** (4) | **4** |
+^ o (others) | **r** (4) | **4** |
+Thus:
+''chmod 644 index.html''
+Et voila!
+===== …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.
+<user-classes><operation><permission-types>[,<user-classes><operation><permission-types>]…
+|1|//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.|
+|2|//operation//|
+| |One of the following:|
+| | ''+'' Add permission types to user classes.|
+| | ''-'' Remove permission types from user classes.|
+| | ''='' Set permission types for user classes.|
+|3|//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:
+''chmod u=rw,go=r index.html''
+would have the same effect as the example command:
+''chmod 644 index.html''
+If I later wanted to give **w** permission to members of the file's user group, I could use the command:
+''chmod g+w index.html''
+===== 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.
+''% chflags uunlnk foo''
+would be used to set the user undelete flag, and to disable that flag, simply add “no” in front of the option (in this example, uunlnk), like so:
+''chflags nouunlnk foo''
+----
+$Id: permissions.html,v 1.8 2007/10/02 11:22:28 papa Exp $ [[http://sdf.org/?tutorials/permissions|File Permissions]] - traditional link (using [[wp>Revision_Control_System|RCS]])