15.4.

2 Permissions on Directories
Directories have the same permission scheme as files. However, the three permis-
sions are interpreted differently:

� Read: The contents (i.e., the list of filenames) of the directory may be listed
(e.g., by ls).
If experimenting to verify the operation of the directory read permission bit,
be aware that some Linux distributions alias the ls command to include flags
(e.g., –F) that require access to i-node information for files in the directory,
and this requires execute permission on the directory. To ensure that we are
using an unadulterated ls, we can specify the full pathname of the command
(/bin/ls).

� Write: Files may be created in and removed from the directory. Note that it is
not necessary to have any permission on a file itself in order to be able to
delete it.
� Execute: Files within the directory may be accessed. Execute permission on a
directory is sometimes called search permission.

When accessing a file, execute permission is required on all of the directories listed
in the pathname. For example, reading the file /home/mtk/x would require execute
permission on /, /home, and /home/mtk (as well as read permission on the file x itself).
If the current working directory is /home/mtk/sub1 and we access the relative path-
name ../sub2/x, then we need execute permission on /home/mtk and /home/mtk/sub2
(but not on / or /home).
Read permission on a directory only lets us view the list of filenames in the
directory. We must have execute permission on the directory in order to access the
contents or the i-node information of files in the directory.
Conversely, if we have execute permission on a directory, but not read permission,
then we can access a file in the directory if we know its name, but we can’t list the
contents of (i.e., the other filenames in) the directory. This is a simple and fre-
quently used technique to control access to the contents of a public directory.
To add or remove files in a directory, we need both execute and write permis-
sions on the directory.

15.4.3 Permission-Checking Algorithm

The kernel checks file permissions whenever we specify a pathname in a system
call that accesses a file or directory. When the pathname given to the system call
includes a directory prefix, then, in addition to checking for the required permis-
sions on the file itself, the kernel also checks for execute permission on each of the
directories in this prefix. Permission checks are made using the process’s effective
user ID, effective group ID, and supplementary group IDs. (To be strictly accurate,
for file permission checks on Linux, the file-system user and group IDs are used
instead of the corresponding effective IDs, as described in Section 9.5.)
Once a file has been opened with open(), no permission checking is performed
by subsequent system calls that work with the returned file descriptor (such as
read(), write(), fstat(), fcntl(), and mmap()).

F i l e A tt r i b u t es 297
 The rules applied by the kernel when checking permissions are as follows:

1. If the process is privileged, all access is granted.

2. If the effective user ID of the process is the same as the user ID (owner) of the
file, then access is granted according to the owner permissions on the file. For
example, read access is granted if the owner-read permission bit is turned on in
the file permissions mask; otherwise, read access is denied.
3. If the effective group ID of the process or any of the process supplementary
group IDs matches the group ID (group owner) of the file, then access is
granted according to the group permissions on the file.
4. Otherwise, access is granted according to the other permissions on the file.
In the kernel code, the above tests are actually constructed so that the test to
see whether a process is privileged is performed only if the process is not
granted the permissions it needs via one of the other tests. This is done to
avoid unnecessarily setting the ASU process accounting flag, which indicates
that the process made use of superuser privileges (Section 28.1).

The checks against owner, group, and other permissions are done in order, and
checking stops as soon as the applicable rule is found. This can have an unexpected
consequence: if, for example, the permissions for group exceed those of owner,
then the owner will actually have fewer permissions on the file than members of
the file’s group, as illustrated by the following example:
$ echo 'Hello world' > a.txt
$ ls -l a.txt
-rw-r--r-- 1 mtk users 12 Jun 18 12:26 a.txt
$ chmod u-rw a.txt Remove read and write permission from owner
$ ls -l a.txt
----r--r-- 1 mtk users 12 Jun 18 12:26 a.txt
$ cat a.txt
cat: a.txt: Permission denied Owner can no longer read file
$ su avr Become someone else…
Password:
$ groups who is in the group owning the file…
users staff teach cs
$ cat a.txt and thus can read the file
Hello world

Similar remarks apply if other grants more permissions than owner or group.
Since file permissions and ownership information are maintained within a file
i-node, all filenames (links) that refer to the same i-node share this information.
Linux 2.6 provides access control lists (ACLs), which make it possible to define
file permissions on a per-user and per-group basis. If a file has an ACL, then a mod-
ified version of the above algorithm is used. We describe ACLs in Chapter 17.

Permission checking for privileged processes

Above, we said that if a process is privileged, all access is granted when checking
permissions. We need to add one proviso to this statement. For a file that is not a
directory, Linux grants execute permission to a privileged process only if that per-
mission is granted to at least one of the permission categories for the file. On some
298 Cha pter 15
 other UNIX implementations, a privileged process can execute a file even when no
permission category grants execute permission. When accessing a directory, a
privileged process is always granted execute (search) permission.
We can rephrase our description of a privileged process in terms of two
Linux process capabilities: CAP_DAC_READ_SEARCH and CAP_DAC_OVERRIDE (Section
39.2). A process with the CAP_DAC_READ_SEARCH capability always has read permis-
sion for any type of file, and always has read and execute permissions for a
directory (i.e., can always access files in a directory and read the list of files in a
directory). A process with the CAP_DAC_OVERRIDE capability always has read and
write permissions for any type of file, and also has execute permission if the
file is a directory or if execute permission is granted to at least one of the per-
mission categories for the file.

15.4.4 Checking File Accessibility: access()

As noted in Section 15.4.3, the effective user and group IDs, as well as supplemen-
tary group IDs, are used to determine the permissions a process has when access-
ing a file. It is also possible for a program (e.g., a set-user-ID or set-group-ID
program) to check file accessibility based on the real user and group IDs of the process.
The access() system call checks the accessibility of the file specified in pathname
based on a process’s real user and group IDs (and supplementary group IDs).

#include <unistd.h>

int access(const char *pathname, int mode);

Returns 0 if all permissions are granted, otherwise –1

If pathname is a symbolic link, access() dereferences it.

The mode argument is a bit mask consisting of one or more of the constants
shown in Table 15-5, ORed (|) together. If all of the permissions specified in mode
are granted on pathname, then access() returns 0; if at least one of the requested per-
missions is not available (or an error occurred), then access() returns –1.
Table 15-5: mode constants for access()

Constant Description
F_OK Does the file exist?
R_OK Can the file be read?
W_OK Can the file be written?
X_OK Can the file be executed?

The time gap between a call to access() and a subsequent operation on a file means
that there is no guarantee that the information returned by access() will still be true
at the time of the later operation (no matter how brief the interval). This situation
could lead to security holes in some application designs.
Suppose, for example, that we have a set-user-ID-root program that uses access()
to check that a file is accessible to the real user ID of the program, and, if so, per-
forms an operation on the file (e.g., open() or exec()).

F i l e A tt r i b u t es 299
 The problem is that if the pathname given to access() is a symbolic link, and a
malicious user manages to change the link so that it refers to a different file before
the second step, then the set-user-ID-root may end up operating on a file for which the
real user ID does not have permission. (This is an example of the type of time-of-
check, time-of-use race condition described in Section 38.6.) For this reason, recom-
mended practice is to avoid the use of access() altogether (see, for example,
[Borisov, 2005]). In the example just given, we can achieve this by temporarily
changing the effective (or file system) user ID of the set-user-ID process, attempting
the desired operation (e.g., open() or exec()), and then checking the return value and
errno to determine whether the operation failed because of a permissions problem.
The GNU C library provides an analogous, nonstandard function, euidaccess()
(or synonymously, eaccess()), that checks file access permissions using the effec-
tive user ID of the process.

15.4.5 Set-User-ID, Set-Group-ID, and Sticky Bits

As well as the 9 bits used for owner, group, and other permissions, the file permis-
sions mask contains 3 additional bits, known as the set-user-ID (bit 04000), set-group-
ID (bit 02000), and sticky (bit 01000) bits. We have already discussed the use of the
set-user-ID and set-group-ID permission bits for creating privileged programs in
Section 9.3. The set-group-ID bit also serves two other purposes that we describe
elsewhere: controlling the group ownership of new files created in a directory
mounted with the nogrpid option (Section 15.3.1), and enabling mandatory locking
on a file (Section 55.4). In the remainder of this section, we limit our discussion to
the use of the sticky bit.
On older UNIX implementations, the sticky bit was provided as a way of mak-
ing commonly used programs run faster. If the sticky bit was set on a program file,
then the first time the program was executed, a copy of the program text was saved
in the swap area—thus it sticks in swap, and loads faster on subsequent executions.
Modern UNIX implementations have more sophisticated memory-management
systems, which have rendered this use of the sticky permission bit obsolete.
The name of the constant for the sticky permission bit shown in Table 15-4,
S_ISVTX, derives from an alternative name for the sticky bit: the saved-text bit.

In modern UNIX implementations (including Linux), the sticky permission bit

serves another, quite different purpose. For directories, the sticky bit acts as the
restricted deletion flag. Setting this bit on a directory means that an unprivileged
process can unlink (unlink(), rmdir()) and rename (rename()) files in the directory
only if it has write permission on the directory and owns either the file or the directory.
(A process with the CAP_FOWNER capability can bypass the latter ownership check.)
This makes it possible to create a directory that is shared by many users, who can
each create and delete their own files in the directory but can’t delete files owned
by other users. The sticky permission bit is commonly set on the /tmp directory for
this reason.

300 Cha pter 15