User accounts, Usergroups, Ownership and Permissions
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, usergroups, ownership and permissions are and mean in detail.
- 1 User Accounts
- 2 Ownership
- 3 Permissions
- 4 See Also
A user account 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, password, userid, primary group, description of account, 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, these cannot be used as login accounts. In Linux-based operating systems, this information is typically stored in the /etc/passwd file, with hashed passwords typically stored in the /etc/shadow file. However, in a networked environment other configuration files may store this information instead.
Every user account in Unix and Linux-based operating systems is a member of at least one 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.
The /etc/group file consists of four fields:
- Group name
- Password - Encrypted password, if empty no password required
- 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".
As mentioned above, everything in a Unix-like and Linux-based operating system has an "owner". 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", with this "owner" simply being a user account on your system.
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.
To just change the owning group, we can 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" usergroup.
-rwx------ 1 james somegroup 0 Jan 23 00:25 foo
If we want to change the owning user on the other hand, we can 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
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:
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 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:
Permissions do slightly vary in meaning between files and directories however as we will see below.
Permissions for files
- r -- read permission
- w -- write permission
- x -- execute permission
Permissions for directories
- r -- allow listing of files and subdirectories in a directory
- w -- allow the modification of files and subdirectories in a directory
- x -- traverse a directory
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 using alphabetic characters
We can use the alphabetic characters rwx to specify specific permissions with the chmod command at the command-line.
Let's say we had the following file called "foo" below, and we wanted to give the owning user read, write and execute permission.
---------- 1 james james 0 Jan 23 00:25 foo
We can see above that the file called "foo" is owned by a user called "james" and the owning group is also called "james", but there is absolutely no permissions set on the file. Well, provided you are logged in as the owning user, or root, and you're sitting in the same directory in this case, you could type the following:
chmod u+rwx foo
Now we should have output from the ls command like this:
-rwx------ 1 james james 0 Jan 23 00:25 foo
You can simply replace the "u" above with "g" to apply or remove permissions from or to the owning group, or with "a" to apply or remove permissions from or to everybody else (also known as "world"). You can also simply replace the "+" with a single dash to remove permissions. See the chmod wiki page for more information.
Modifying permissions using octal notation
It's not by coincidence that there is a mathematical base called base8, that is otherwise known as "octal notation" that is 0 - 7 in range. You'll also note that adding 4 + 2 + 1 gives you seven, and you cannot get a higher result, again this isn't just coincidence. This is because the chmod command in Unix-like systems allow you to use octal notation instead of alphabetic characters to change permissions. There is more information and examples about octal notation under the heading "Numeric permissions" in the chmod wiki page. We will list some examples of using chmod to change permissions using octal notation below the following permissions table.
Table of the permissions with their respective octal notation:
Let's say we wanted to gave the owning user just read permission to a file called "foo" and no other permission. We could do just that with the following command:
chmod 400 foo
Assuming that the file "foo" has an owning user and group called "james", the
ls -la command would display something similar to the following:
-r-------- 1 james james 0 Jan 23 01:35 foo
Let's say we wanted to give the owning user read permission and everyone else (including the owning user) "execute" permission for the file called "foo". We could use the following command:
chmod 511 foo
Notice how the output of the ls command has changed below:
-r-x--x--x 1 james james 0 Jan 23 01:35 foo
In one more example, we will give the owning user read, write and execute permission, and everyone else just read permission.
chmod 744 foo
Notice how the output of
ls -la has changed once again:
-rwxr--r-- 1 james james 0 Jan 23 01:35 foo
Note: It's usually a very bad idea for security reasons to give everyone full read, write and execute permissions using
chmod 777 So please try and avoid doing that wherever possible, as it defeats the purpose of permissions.