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 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 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.
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.
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 21.1. “Sample Output Showing File Permissions”.
Example 21.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.
|Type||Users Permissions||Group Permissions||Permissions 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 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). See 21.2.6. “Access Control Lists” for details and refer to the chapter in the Administration Guide for further background information.
Access permissions for directories have the type d. For directories, the individual permissions have a slightly different meaning.
Example 21.2. Sample Output Showing Directory Permissions
drwxrwxr-x 1 tux project3 35 Jun 21 15:15 ProjectData
In Output 21.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 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).
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 file names. The parameters form different categories:
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)
a character for deletion (–), setting (=), or insertion (+)
r — read
w — write
x — execute
file name or names separated by spaces
If, for example, the user tux in Example 21.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 write to the file without first reestablishing write 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 21.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 Output 21.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.
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 burning 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.
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 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
There is also 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. 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
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 can be detected with a simple ls -l command:
-rw-r--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. Find further background information about ACLs in the Administration Guide.