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. This resulted in some notable distinctions from the Microsoft end-user Windows operating systems.

The most important distinguishing feature is the necessity for users to log in to the system before starting a session at their workstation. Each user has a user name 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 has 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 the super user 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.

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 Output Example 24.1.

Example 24.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.

-rw-r-----
TypeUsers PermissionsGroup PermissionsPermissions for Other Users

This column is comprised 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 dash () 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 dash () 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 our 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). See Section “Access Control Lists” for details and refer to the chapter Access Control Lists in Linux in the Administration Guide for further background information.

Directory Permissions

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

Example 24.2. Sample Output Showing Directory Permissions

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

In Output Example 24.2, the owner (tux) and the owner group (project3) of the directory ProjectData are easy to recognize. In contrast to the file access permissions from Section File Access, the set reading permissions (r) means that the contents of the directory can be shown. The write permission (w) means new files can be created. The executable permission (x) means the user can change to this directory. In the above example, this means 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 new files to it (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).

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, which must be entered together with the parameters specifying the changes to perform and the names of the respective files.

Both parameters are comprised of

  1. the categories 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. file name or names separated by spaces

If, for example, the user tux in the example Example 24.2 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 write to the file 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 the example Example 24.2 should no longer belong to tux, but to the user geeko. The command root should 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 Output Example 24.1 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.

The setuid Bit

In certain situations, the access permissions may be too restrictive. Therefore, Linux has additional settings that enable the temporary change of the current user and group identity for a specific action.

For example, the cdrecord program normally requires root permissions to access the writer for writing CDs (or DVDSs). Thus, a normal user would not be able to create CDs, as it would be too dangerous to grant all users direct access to all devices.

A possible solution to this problem is the setuid mechanism. setuid (set user ID) is a special file attribute that instructs the system to execute programs marked accordingly under a specific user ID. Consider the cdrecord command:

-rwxr-x---  1 root root  281356 2002-10-08 21:30 /usr/bin/cdrecord

Set the setuid bit with the command chmod u+s /usr/bin/cdrecord. Then, assign the cdrecord program to the group users with the command chgrp users /usr/bin/cdrecord.

The following access permissions are granted:

-rws--x---  1 root users  281356 2002-10-08 21:30 /usr/bin/cdrecord

By means of the setuid bit, all users belonging to the group users can use the program. In effect, this means that the program is executed as root.

Warning

Setting the setuid bit for a program makes your computer more vulnerable to attacks. Only do this in exceptional cases when you know the program well and are aware of the potential risks.

The setgid Bit

The setuid attribute applies to users. However, there is also an equivalent property for groups — the setgid attribute. A program for which this attribute was set runs under the group ID under which it was saved, no matter which user starts it. Therefore, in a directory with the setgid bit, all newly created files and subdirectories are assigned to the group to which the directory belongs. Consider the following example directory:

drwxrwxr--  2 root archive   48 Nov 19 17:12 backup

Set the setuid bit with the command chmod g+s /test.

Subsequently, the access permissions appear as follows:

drwxrwxr--   2 root archive   48 Nov 19 17:12 backup

The Sticky Bit

Apart from the setuid and setgid bits, there is the sticky bit. It makes a difference whether it belongs to an executable program or a directory. If it belongs to a program, a file marked in this way will be loaded to the RAM to avoid needing to get it from the hard disk each time it is used. Nowadays, this attribute is used rarely, as modern hard disks are fast enough.

If this attribute is assigned to a directory, it prevents users from deleting each other's files. Typical examples include the /tmp and /var/tmp directories:

drwxrwxrwt   2 root  root   1160 2002-11-19 17:15 /tmp
  

Access Control Lists

The traditional permission concept for Linux file system objects, such as files or directories, can be expanded by means of ACLs (Access Control Lists). They allow the assignment of permissions to individual users or groups other than the original owner or owning group of a file system object.

Files or directories bearing extended access permissions reveal themselves after the execution of a simple ls -l command:

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

The output of ls does not reveal much of a change compared to an ls on a file without an ACL. Roadmap is owned by tux who belongs to the group project3. tux holds both write and read access to this file and his group as well as all other users have read access. The only difference that distinguishes this file from a file without an ACL is the additional + in the first column holding the permission bits.

Get details about the ACL by executing getfacl Roadmap:

# file: Roadmap
# owner: tux
# group: project3
user::rw-
user:jane:rw-       effective: r--
group::r--
group:djungle:rw-   effective: r--
mask::r--
other::---

The first three lines of the output do not hold any information not available with ls -l. These lines only state file name, owner, and owning group. Lines 4 to 9 hold the ACL entries. Conventional access permissions represent a subset of those possible when using ACLs. Our example ACL grants read and write access to the owner of the file as well as to a user jane (lines 4 and 5). The conventional concept has been expanded allowing access to an extra user. The same applies to the handling of group access. The owning group holds read permissions (line 6) and the group djungle holds read and write permissions. The mask entry in line 8 reduces the effective permissions for the user jane and the group djungle to read access. Other users and groups do not get any kind of access to the file (line 9).

Only very basic information has been provided here. Findfurther background information about ACLs in Access Control Lists in Linux in the Administration Guide.