Users, Groups, Ownership and Permissions
Overview
Like other Unix-like systems, Linux-based operating systems are inherently multiuser operating systems and enforce a user privilege system to control access to system resources. This includes, user accounts, user groups, ownership, and permissions, which in turn dictate what access is granted to, among other resources, files, directories (also known as "folders") and processes. This user privilege system works in the same way on any Linux distribution. For example, each file, directory and running process has an owner, as well as a set of permissions associated with it. There is also one account that can perform any operation possible, even where no permissions have been explicitly granted to it. This user account is called the root user account, also known as the "superuser". In fact, most files and directories outside of user profiles stored in the /home directory tree are "owned" by the root user. This "protects" them from being modified incorrectly, as you would need to explicitly gain "root user privileges" in order to be able to actually modify them in any way.
Below we will discuss what user accounts, user groups, ownership and permissions are and mean in detail.
User Accounts
In computing, a "user" not only usually refers to a person, but often a "user account" that uniquely identifies a user of a particular system, be that an operating system, an online forum, etc. A user account allows a system to grant said user a particular set of privileges, that govern access to system resources, such as files, directories, etc. A user account has a set of metadata associated with it, that define particular details pertaining to said user account. For instance, and in Unix-like systems such as Linux this includes, the human-friendly account name (normally called a "username"), password, UID, primary group GID, GECOS field, their "home" directory and default shell. A user account can also be a "service account" to run system services ("services" are otherwise known as "daemons") under, typically these user accounts cannot be used as login accounts.
Every process runs in the name of some user called the owner. The top command lists processes along with the owners. Files and other system resources are protected and can only be accessed by particular users. Sending signals can only be done by the user or the root user of the process being signalled.
In Linux-based operating systems where user authentication is done locally, this information is stored in the /etc/passwd file, with hashed passwords stored in the /etc/shadow file. However, in a networked environment other configuration files may store this information instead, where user authentication is not done locally.
User groups
Every user account in Unix and Linux-based operating systems is a member of at least one user group (often just called a "group"), which is known as their "primary group", with a group simply being a "container" for different user accounts. Groups in Linux-based operating systems are defined in the /etc/group file, which also defines which user accounts are members of a given group. One example of why we have "groups" is so a system administrator (also known as a "sysop" or "sysadmin") can assign permissions or other restrictions on an entire group of users, rather than only one user on a per user basis. This is often beneficial when more than one user should have the same access rights to a particular object or similar.
The /etc/group file consists of four fields:
- Group name
- Password - Encrypted password, if empty no password required
- GID
- User list - Members of the group, separated by commas
UID and GID
UID (also known as a userid) stands for User Identifier. GID stands for Group Identifier. These are unique numbers assigned to each user account and group respectively. Usually UID's start from 1000 for each user account created during the installation of a Linux distribution, including user accounts created post-installation. The root user account always has a UID of 0, this is in-fact what gives it "superpowers".
Ownership
As mentioned above, everything in a Unix-like and Linux-based operating system has an "owner", for files and directories this includes an owning user and an owning group. Like in relation to physical property, the "owner" has a set of rights over what it "owns". In Linux this includes, and for example, the right to set permissions on the object it "owns", and changing the ownership of an object on the system.
Example:
ls -l total 12345 -rwx-r--r-- 1 tom users 1028 2006-12-01 00:00 Bobs file
In this example "tom" is the "owner" of the file called "Bobs file", he belongs to the group "users". "-rwx-r--r--" describes the permissions for the file "Bobs file".
Changing ownership of a file or directory
For a number of reasons you might want or need to change the ownership of a file or directory, or even a number of files and/or directories. There are a couple of commands you can use depending on exactly what it is you wish to change the ownership of. These commands are the chown and chgrp commands, which we will give examples of below.
If we want to change the owning user, we use the chown command. This command has the benefit of being able to change both the owning user and the owning group at the same time.
In the example below we once again have a file called "foo" which has an owning user called "james", along with an owning group also called "james". To change the owning user to "someuser" and the owning group to "somegroup" at the same time, we can run the command below.
chown someuser:somegroup foo
Now as we can see below, the owning user is "someuser" and the owning group for the file called "foo" is "somegroup".
-rwx------ 1 someuser somegroup 0 Jan 23 00:25 foo
To just change the owning group on the other hand, we use the chgrp command. In the example below we change the owning group from "james" to "somegroup" for the file called "foo".
chgrp somegroup foo
Now as we see below, the file called "foo" is owned by the "somegroup" user group.
-rwx------ 1 james somegroup 0 Jan 23 00:25 foo
Permissions
Permissions provide a mechanism by which we can control access to a particular object, be that a filesystem object, such as a file, be that a running process. Without this mechanism, anyone would have complete access to any object on your system, and would be able to do anything they liked with it. Linux-based systems, like Unix, are multitasking systems that permit many different user accounts and therefore users (including at the same time), therefore we need some sort of user privilege system in place to control access to various objects. Without permissions, there would be no way to control access to system resources, therefore every object has a set of permissions associated with it. Default permissions are set by umask on any file created on any Unix/Linux filesystem.
In Unix-like systems and Linux, 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:
-rw-r--r--
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. Permissions do slightly vary in meaning between files and directories however as we will see below.
Octal Notation
We can also use "octal notation" when specifying permissions instead of alphabetic characters. There are some examples of "octal notation" in the chmod page of this wiki.
| Permission | Alphabetic character | Octal notation |
|---|---|---|
| read | r | 4 |
| write | w | 2 |
| execute/traverse | x | 1 |
File type
The first permission bit tells you what type of file you're looking at, the following characters denote the type of file.
The file type (the first character) is denoted with a single character:
- - ordinary file
- d directory
- l (symbolic) link
- b block device
- c character device
- p pipe
- s socket
Permissions for files
Below is how the permission types relate to files in Linux.
| Permission | Meaning |
|---|---|
| read | permission to read a file's contents |
| write | permission to write/modify a file's contents or delete a file |
| execute | permission to execute an executable file |
Permissions for directories
The meaning of some of the permission types has a slightly different meaning for directories/folders in Linux, as described in the table below.
| Permission | Meaning |
|---|---|
| read | allow listing of files and subdirectories in a directory |
| write | allow the modification or creation of files and subdirectories in a directory or delete directory contents |
| execute/traverse | traverse/enter a directory |
Evaluating permissions
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.
Modifying permissions
See the chmod page for examples of how to modify permissions.
See Also
- Access Control List
- GNU Coreutils documentation
- User Identifier