Unix and Unix-like systems associate with each file a number of properties for security and other reasons. One set of properties, known as permissions are special attributes which control the ability of users to perform various operations on them.
Unix and Unix-like systems such as Linux, are inherently multiuser operating systems, and have the need to issue greater control, so that one malicious user cannot interfere with another users files. For example, one user may have sensitive information that another user may want to access. Without file permissions, the other user may be able to access them. With them, the user can't read the file.
On the above systems, each and every file, directory, or device has a set of permissions associated with it. These permissions are visible if one does a ls with the -l flag, which may show something like
-rw-r--r-- 1 root root 1059 Dec 18 13:23 /etc/passwd
The permissions block is the first thing on the line:
We break this string up into four sections:
- rw- r-- r--
- The first block of one character represents the file type (see below).
- The second block represents the permissions associated with the user (who created it)
- The third represents the permissions associated with the group the user belongs to
- The fourth represents the permissions associated with everyone else (often termed world).
- SELinux shows a dot als fifth character if a security context exists for the file entry.
In each block of three characters, the r, w, and x characters signify that the file can be read, written to, or executed. A dash means the permission is not set (eg in 1 above, the file can be read and written by the owner, but not executed). So, for example r-x means that read and execute permissions are set, but not write.
The file type (the first character) is denoted with a single character:
Permissions on directories work differently than for files.
- r -- required to ls the files in the directory
- w -- required to created, delete, or modify any files or subdirectories
- x -- required to cd into the directory; contents can be read if their names are already known
Changing permissions and ownerships
Many permissions are automatically set when a file is created. These permissions are based on user and administrative preferences and data.
Every file is automatically assigned a set of permissions, which can be set by the umask command. To change the permissions from this default, the chmod is used, which modifies a file's read, write, and execute permissions for user, group, and world.
Every file has an owner. When a file is created by a user, this is automatically assigned, though the file's owner can be changed (that is, the file can be "given" to someone), by use of the chown command, for example
chown john ~/john's_todo_list
changes the owner from the creator of john's_todo_list to the user john.
Every file belongs to a group. This could be the user's own group (a user can belong to a group containing only that user), or another wider group, such as publishers, for example.
Again, the automatic group assignment can be changed by the chgrp command. For example, if the file final_draft belonged to the writers group, to change the group to the publishers group can be done by
chgrp publishers ~/final_draft
Owner and group may be changed simultaneously using
chown newuser:newgroup filename
When determining who has permission to do what with a file, only the most specific permission is evaluated. Take the following completely fictional file:
-r---w---x 1 james webusers 1059 Dec 18 13:23 foo.sh
This indicates that james (and only james) can read foo.sh. james cannot write or execute foo.sh (footnote: missing x permission on a shellscript can be gotten around by running it by the appropriate shell: "
bash foo.sh"). Members of the webusers group can only write to foo.sh, and cannot read or run it. If james is a member of the webusers group, he still cannot write to the file, because only the Owner permissions (the most specific) apply to james. Everyone who is not james, or a member of webusers, can execute foo.sh, but not read or write it. (footnote: In reality, shell scripts require read permissions to execute)
There is a 4th bit for each permission as well. The Owner's fourth bit is suid, which causes a program to always be executed as the Owner, regardless of the user who runs the program. The Group's fourth bit has two purposes: on files, it is sgid, and causes the program to always execute in that group. On directories, it causes all new files written to that directory to belong to that group automatically. The World's fourth bit is called sticky. Its most common use is on directories, where it prevents users from deleting files owned by someone else, even if they have write access to the directory (it is often used on mail spools and on /tmp). In a normal
ls -l listing, suid and sgid are marked with "s" in place of "x". If s is set, but x is unset, then ls will display "S" instead. The sticky bit appears as "t" in place of x, and as T when x is unset. With all bits set: rwsrwsrwt, or after
chmod -x: rwSrwSrwT.
The precise meanings of read, write and execute can vary depending on the type of object (for example, a file or directory), in addition there may be other permissions that can be applied depending on the type of filesystem in use.
Permissions may also be applied to network resources such as file or printer shares.
- GNU Coreutils documentation