Problem - Kevin Tafuro

of the object, regardless of what the object’s DACLsays. Unfortunately, if an object
is not sufficiently protected, an attacker can nefariously take ownership of the object,
rendering the rightful owner powerless to counter the attacker.
2.3 Determining Whether a User Has Access to
a File on Unix
Problem
Your program is running with extra permissions because its executable has the setuid
or setgid bit set. You need to determine whether the user running the program
will be able to access a file without the extra privileges granted by setuid or setgid.
Solution
Temporarily drop privileges to the user and group for which access is to be checked.
With the process’s privileges lowered, perform the access check, then restore privileges
to what they were before the check. See Recipe 1.3 for additional discussion of
elevated privileges and how to drop and restore them.
Discussion
It is always best to allow the operating system to do the bulk of the work of performing
access checks. The only way to do so is to manipulate the privileges under which
the process is running. Recipe 1.3 provides implementations for functions that temporarily
drop privileges and then restore them again.
When performing access checks on files, you need to be careful to avoid the types of
race conditions known as Time of Check, Time of Use (TOCTOU), which are illustrated
in Figures 2-1 and 2-2. These race conditions occur when access is checked
before opening a file. The most common way for this to occur is to use the access( )
system call to verify access to a file, and then to use open( ) or fopen( ) to open the
file if the return from access( ) indicates that access will be granted.
The problem is that between the time the access check via access( ) completes and
the time open( ) begins (both system calls are atomic within the operating system kernel),
there is a window of vulnerability where an attacker can replace the file that is
being operated upon. Let’s say that a program uses access( ) to check to see whether
an attacker has write permissions to a particular file, as shown in Figure 2-1. If that
file is a symbolic link, access( ) will follow it, and report that the attacker does
indeed have write permissions for the underlying file. If the attacker can change the
symbolic link after the check occurs, but before the program starts using the file,
pointing it to a file he couldn’t otherwise access, the privileged program will end up
Determining Whether a User Has Access to a File on Unix | 43
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.