Difference between revisions of "Linux Permissions"
Chris Tyler (talk | contribs) m (→Symbolic Representation) |
Chris Tyler (talk | contribs) |
||
(11 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | Linux and Unix systems use a permission mechanism that is simple and robust. | + | 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 = | = Ownership = | ||
Line 35: | Line 35: | ||
These permissions are interpreted slightly differently on a directory: | 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 | + | * 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. | * 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. | * execute - the ability to open files and directories within the directory. | ||
Line 76: | Line 76: | ||
You can view the permission on a file using the <code>-1</code> argument to the <code>ls</code> command. You can also view file permissions using most graphical file managers, such as Nautilus (GNOME) or Konqueror (KDE), although you will need to change from the default view settings. | You can view the permission on a file using the <code>-1</code> argument to the <code>ls</code> command. You can also view file permissions using most graphical file managers, such as Nautilus (GNOME) or Konqueror (KDE), although you will need to change from the default view settings. | ||
+ | |||
+ | = Setting the Permission Mode = | ||
+ | |||
+ | Permissions are set from the command line using the <code>chmod</code> command. (You can also change permissions with most graphical file managers). | ||
+ | |||
+ | == Setting the Permission in Octal == | ||
+ | |||
+ | 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]] |
Latest revision as of 21:43, 15 September 2008
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 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.
Contents
Ownership
Each file has an owner and group-owner. The original file owner is the creator of the file; the superuser (root) can reassign the ownership of the file. The default group of the creator of the file is the original group-owner; the current owner of the file can change the group-owner to be any of the groups to which she belongs, or the superuser can change the group to any group on the sytem.
Here's an example: imagine that the user Jane belongs to the groups toronto (default group), seneca, and baseball. She creates the file "automate"; viewing the file with ls -l
shows this display:
-rwxrw-r-- 1 jane toronto 2019 2008-09-15 11:25 automate
Note that jane is the owner, and toronto is the group-owner.
Jane cannot change the user, but the superuser can change it to any user of the system using the chown
command.
Jane can change the group-owner to seneca or baseball, or the superuser can change it to any group on the system, using the chgrp
command.
Communities
There are three communities of users in the system:
- user - the owner of the file
- group - users in the group that is the group-owner of the file
- other - everyone else
The order and initials of these communities is important: u-g-o
Permissions
Each of the three communities has three permissions:
- read - the ability to read (view, play, copy) the file
- write - the ability to write (change, truncate, append) the file
- execute - the ability to execute (run) the file
These permissions are interpreted slightly differently on a directory:
- read - the ability to search for files within the directory (e.g., "ls" or use 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.
Note that a user with read but not execute permission on a directory may see the files in a directory but not use them; a user with execute but not read permission may use files in the directory but must know the exact filename (because they can't list the directory contents).
Permission Mode
A full permission mode consists of the three permissions for each of the three communities. In addition, there may be some Extended Permissions (see below).
Symbolic Representation
A permission may be represented as a string of nine r, w, x, and - characters. The first three characters represent the permissions for the user, the second set of three represent the permissions for the group, and the last three represent the permissions for others. Each group consists of the letters r, w, and x in order for permissions that are turned on, or - for permissions that are not turned on.j
The output of ls -l
starts with character representing the file type (- for regular files, d for directories, and other characters for special files) followed by the 9-character symbolic representation of the permission mode:
-rwxrw-r-- 1 jane toronto 2019 2008-09-15 11:25 automate
In this case, the mode is rwxrw-r--
, which breaks down as:
- user permission: rwx (read, write, and execute permission are enabled/granted to the user jane)
- group permission: rw- (read and write permission are granted to users in the toronto group, but execute permission is denied)
- other permission: r-- (read permission is granted for all other users, write and execute permission is denied)
Octal Representation
It is also possible to represent a permission as a group of octal digits. Each digit represents the permission for one community, in u-g-o order. The value of the digit is the sum of the enabled permissions using these values:
- read: 4
- write: 2
- execute: 1
Therefore, the symbolic mode "rwxrw-r--" can be encoded in represented in octal as 764, since:
- user permission = rwx = 4+2+1 = 7
- group permission = rw- = 4+2 = 6
- other permission = r-- = 4
Viewing the Permission Mode
You can view the permission on a file using the -1
argument to the ls
command. You can also view file permissions using most graphical file managers, such as Nautilus (GNOME) or Konqueror (KDE), although you will need to change from the default view settings.
Setting the Permission Mode
Permissions are set from the command line using the chmod
command. (You can also change permissions with most graphical file managers).
Setting the Permission in Octal
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 chmod
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 g+r
, which adds read permission for the group but does not affect the write and execute permission, u=r
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
getfacl
andsetfacl
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.