|
 |
|
| |
18.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.
18.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 18-1.
Example 18-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.
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 18-2
Sample Output Showing Directory Permissions
drwxrwxr-x 1 tux project3 35 Jun 21 15:15 ProjectData
In Example 18-2, the owner (tux) and the owning group
(project3) of the directory
ProjectData are easy to recognize. In
contrast to the file access permissions from , 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).
18.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:
-
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
-
Filename or filenames separated by spaces
If, for example, the user tux in Example 18-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 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 18-2 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 18-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.
|
|
|
