3.2. Users and Access Permissions

Since its inception in the early 1990s, Linux has been developed as a multiuser system. Any number of users can work on it simultaneously. Users need to log in to the system before starting a session at their workstations. Each user has a username with a corresponding password. This differentiation of users guarantees that unauthorized users cannot see files for which they do not have permission. Larger changes to the system, such as installing new programs, are also usually impossible or restricted for normal users. Only the root user, or super user, has the unrestricted capacity to make changes to the system and unlimited access to all files. Those who use this concept wisely, only logging in with full root access when necessary, can cut back the risk of unintentional loss of data. Because under normal circumstances only root can delete system files or format hard disks, the threat from the Trojan horse effect or from accidentally entering destructive commands can be significantly reduced.

3.2.1. File System Permissions

Basically, every file in a Linux file system belongs to a user and a group. Both of these proprietary groups and all others can be authorized to write, read, or execute these files.

A group, in this case, can be defined as a set of connected users with certain collective rights. For example, call a group working on a certain project project3. Every user in a Linux system is a member of at least one proprietary group, normally users. There can be as many groups in a system as needed, but only root is able to add groups. Every user can find out, with the command groups, of which groups he is a member.

File Access

The organization of permissions in the file system differs for files and directories. File permission information can be displayed with the command ls -l. The output could appear as in Example 3.1, “Sample Output Showing File Permissions”.

Example 3.1. Sample Output Showing File Permissions

-rw-r----- 1 tux project3 14197 Jun 21  15:03 Roadmap

As shown in the third column, this file belongs to user tux. It is assigned to the group project3. To discover the user permissions of the Roadmap file, the first column must be examined more closely.






Users Permissions

Group Permissions

Permissions for Other Users

This column consists of one leading character followed by nine characters grouped in threes. The first of the ten letters stands for the type of file system component. The hyphen () shows that this is a file. A directory (d), a link (l), a block device (b), or a character device could also be indicated.

The next three blocks follow a standard pattern. The first three characters refer to whether the file is readable (r) or not (). A w in the middle portion symbolizes that the corresponding object can be edited and a hyphen () means it is not possible to write to the file. An x in the third position denotes that the object can be executed. Because the file in this example is a text file and not one that is executable, executable access for this particular file is not needed.

In this example, tux has, as owner of the file Roadmap, read (r) and write access (w) to it, but cannot execute it (x). The members of the group project3 can read the file, but they cannot modify it or execute it. Other users do not have any access to this file. Other permissions can be assigned by means of ACLs (access control lists).

Directory Permissions

Access permissions for directories have the type d. For directories, the individual permissions have a slightly different meaning.

Example 3.2. Sample Output Showing Directory Permissions

drwxrwxr-x 1 tux project3 35 Jun 21 15:15  ProjectData

In Example 3.2, “Sample Output Showing Directory Permissions”, the owner (tux) and the owning group (project3) of the directory ProjectData are easy to recognize. In contrast to the file access permissions from File Access , the set reading permission (r) means that the contents of the directory can be shown. The write permission (w) means that new files can be created. The executable permission (x) means that the user can change to this directory. In the above example, the user tux as well as the members of the group project3 can change to the ProjectData directory (x), view the contents (r), and add or delete files (w). The rest of the users, on the other hand, are given less access. They may enter the directory (x) and browse through it (r), but not insert any new files (w).

3.2.2. Modifying File Permissions

Changing Access Permissions

The access permissions of a file or directory can be changed by the owner and, of course, by root with the command chmod followed by the parameters changing the permissions and one or more filenames. The parameters form different categories:

  1. Users concerned

    • u (user)—owner of the file

    • g (group)—group that owns the file

    • o (others)—additional users (if no parameter is given, the changes apply to all categories)

  2. A character for deletion (), setting (=), or insertion (+)

  3. The abbreviations

    • rread

    • wwrite

    • xexecute

  4. Filename or filenames separated by spaces

If, for example, the user tux in Example 3.2, “Sample Output Showing Directory Permissions” also wants to grant other users write (w) access to the directory ProjectData, he can do this using the command chmod o+w ProjectData.

If, however, he wants to deny all users other than himself write permissions, he can do this by entering the command chmod go-w ProjectData. To prohibit all users from adding a new file to the folder ProjectData, enter chmod -w ProjectData. Now, not even the owner can create a new file in the directory without first reestablishing write permissions.

Changing Ownership Permissions

Other important commands to control the ownership and permissions of the file system components are chown (change owner) and chgrp (change group). The command chown can be used to transfer ownership of a file to another user. However, only root is permitted to perform this change.

Suppose the file Roadmap from Example 3.2, “Sample Output Showing Directory Permissions” should no longer belong to tux, but to the user geeko. root should then enter chown geeko Roadmap.

chgrp changes the group ownership of the file. However, the owner of the file must be a member of the new group. In this way, the user tux from Example 3.1, “Sample Output Showing File Permissions” can switch the group owning the file ProjectData to project4 with the command chgrp project4 ProjectData, as long as he is a member of this new group.