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 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 Example 19.1, “Sample Output Showing File Permissions”.
Example 19.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-- | --- |
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 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). See
Section 19.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 19.2. Sample Output Showing Directory Permissions
drwxrwxr-x 1 tux project3 35 Jun 21 15:15 ProjectData
In Example 19.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 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
).
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:
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)
a character for deletion (–
), setting
(=
), or insertion (+
)
the abbreviations
r
—read
w
—write
x
—execute
filename or filenames separated by spaces
If, for example, the user tux
in Example 19.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 19.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 19.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
passwd program normally requires root permissions to
access /etc/passwd
. This file contains some important
information, like the home directories of users and user and group
IDs. Thus,
a normal user would not be able to change
passwd
, because it
would be too dangerous to grant all users direct access to this file. 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
passwd command:
-rwsr-xr-x 1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd
You can see the s
bit set for the user permission.
By means of the setuid bit, all users starting the passwd
command execute it as root
.
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:
drwxrws--- 2 tux archive 48 Nov 19 17:12 backup
You can see the s
bit set for the group permission.
The owner of the directory and members of the group archive
may access this directory. Users
that are not members of this group are “mapped” to the
respective group. The effective group ID of all written files will be
archive
. For example, a backup
program that runs with the group ID archive
is able to access this
directory even without root privileges.
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 is loaded to RAM to avoid needing to get it from the hard disk
each time it is used. This attribute is used rarely, because 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 filename,
owner, and owning group. Lines 4 to 9 hold the ACL entries. Conventional
access permissions represent a subset of those possible when using ACLs. The
example ACL grants read and write access to the owner of the file as well as
to 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 more detailed information about ACLs in the Administration Guide.