1,885
edits
Changes
no edit summary
Linux and Unix systems use a file permission mechanism that is simple and robust. Although this system is simple, and more powerful alternatives are available (see [[Linux Permissions#Other Permission Systems|Other Permission Systems]]), the simplicity of the Linux/Unix permission system has ensured that it actually gets used where more complex systems may not be. Since Linux treats devices as files, this same permission system works for devices.
= Ownership =
These permissions are interpreted slightly differently on a directory:
* read - the ability to search for files within the directory (e.g., "ls" or use [[Linux Ambiguous Filenames||ambiguous filenames]].
* write - the ability to add files to the directory, remove files from the directory, or change the names of files in the directory.
* execute - the ability to open files and directories within the directory.
To set a permission using an octal value:
chmod ''mode'' ''filenames...'''
For example,
chmod 0751 newscript
chmod 0769 oldscript1 oldscript2
Which will change the permission mode to rwxr-x--x on the file "newscript" and rwxrw---- on "oldscript1" and "oldscript2".
== Setting the Permission using Relative Symbolic Notation ==
You can also set a permission using a variation on symbolic notation. One or more relative permissions operations are given, using this format:
''community'' ''operator'' ''permissions''
Where
* ''community'' is any combination of u, g, o (user/group/other) or a for all (which is the same as "ugo").
* ''operator'' is + to add a permission, - to remove a permission, or = to set a permission
* ''permissions'' is any combination of r, w, x (read/write/execute)
If multiple operations are specified, they are separated by commas with no space. The relative symbolic notation replaced the octal mode in the <code>chmod</code> command.
Here are some examples:
chmod o+r test1
Adds read permission for others on the file "test1". No other permissions are changed.
chmod a-x test2
Removes execute permission for everyone (user, group, and other) on the file "test2". No other permissions are changed.
chmod ug-rwx test3
Removes all permissions (read, write, and execute) for group and other on the file "test3". The user's permissions are not changed.
chmod g=r test4
Sets the group permissions to r-- on the file "test4". Unlike <code>g+r</code>, which adds read permission for the group but does not affect the write and execute permission, <code>u=r</code> will turn off the write and execute permission.
chmod u=rwx,g=rx,o= test5
Sets the user permission to rwx, the group permission to r-x, and the other permission to --- on the file "test5".
chmod a+r,u+wx,go-wx
Sets read permission for everyone, adds write and execute permission for the user, and turns off write and execute permission for others.
= Special Permissions =
In addition to the nine basic permission bits, there are three additional special permissions:
* set-user-id (suid) -- when the file is executed, it takes on the effective user ID of the owner of the file (usually, the effective user ID is that of the person running the program). For example, if the user "frank" runs the command /usr/bin/passwd, which has the set-user-id bit set and which is owned by root, then the program runs with the privileges assigned to the root user. This permits the passwd program to change the files /etc/passwd and /etc/shadow, which frank is normally not permitted to do.
* set-group-id (sgid) -- when the file is executed, it takes on the effective group ID of the group-owner of the file. On a directory, when the group-execute bit is set, this indicates that files created within the directory inherit their group ID from the directory, not from the person creating the directory. Directories created there will automatically have the sgid bit set. (On a file that does not have the group execute bit set, the set-group-id bit indicates that mandatory file/record locking is to be used. This is a rare use of set-group-id!).
* sticky bit -- on old systems, this meant that the file was not swapped out and stuck around in memory; this is no longer the case. However, on a directory, the sticky bit means that a file in that directory can be renamed or deleted only by the owner of the file, the owner of the directory, or the superuser.
When represented in octal, these bits have the following values:
* suid: 4
* sgid: 2
* sticky: 1
The sum of these values forms a fourth octal digit, which is prepended to the four digits used for the regular permissions.
In symbolic representation, these special permissions change the appearance of the "x" (execute) permission:
* the suid bit appears in the user-execute position as an "s"
* the sgid bit appears in the group-execute position as an "s"
* the sticky bit appears in the other-execute position as a "t"
The letter is capitalized if the corresponding execute permission is enabled, and in lowercase if the corresponding execute permission is disabled. For example:
rwsr-xr-x
The file has rwxr-xr-x permission, plus the suid bit is set.
rwxr-sr-x
The file has rwxr-xr-x permission, plus the sgid bit is set.
rwxr-Sr-T
The file has rwxr--r-- permission, plus the sgid and sticky bits are set.
= Other Permission Systems =
In addition to the file permission mode, there are two other common access control schemes which may come into play:
* File Access Control Lists (FACLs) are user-by-user and group-by-group permissions which extend the file permission mode model to have greater granularity. See the <code>getfacl</code> and <code>setfacl</code> commands for more information.
* SELinux is a mandatory access control system. Each file and each process has a "security context", and the SELinux policy dictates what is permitted to happen. This can be used to prevent a program from altering files it should not have access to.
[[Category:Linux]]