Users, Groups, Ownership and Permissions

From LQWiki
(Redirected from Permissions)
Jump to navigation Jump to search

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--
  1. The first block of one character represents the file type (see below).
  2. The second block represents the permissions associated with the user (who created it)
  3. The third represents the permissions associated with the group the user belongs to
  4. The fourth represents the permissions associated with everyone else (often termed world).
  5. 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