Problem - Kevin Tafuro

is unchanged so that the effective ID can later be restored to the higher privilege.
These rules apply to both group and user IDs.
One more issue needs to be addressed with regard to dropping privileges. In addition
to the effective, real, and saved group IDs of a process, a process also has ancillary
groups. Ancillary groups are inherited by a process from its parent process, and
they can only be altered by a process with superuser privileges. Therefore, if a process
with superuser privileges is dropping these privileges, it must also be sure to
drop any ancillary groups it may have. This is achieved by calling setgroups( ) with a
single group, which is the real group ID for the process. Because the setgroups( ) system
call is guarded by requiring the effective user ID of the process to be that of the
superuser, it must be done prior to dropping root privileges. Ancillary groups should
be dropped regardless of whether privileges are being dropped permanently or temporarily.
In the case of a temporary privilege drop, the process can restore the ancillary
groups if necessary when elevated privileges are restored.
The first of two functions, spc_drop_privileges( ) drops any extra group or user privileges
either permanently or temporarily, depending on the value of its only argument.
If a nonzero value is passed, privileges will be dropped permanently; otherwise, the
privilege drop is temporary. The second function, spc_restore_privileges( ), restores
privileges to what they were at the last call to spc_drop_privileges( ). If either function
encounters any problems in attempting to perform its respective task, abort( ) is
called, terminating the process immediately. If any manipulation of privileges cannot
complete successfully, it’s safest to assume that the process is in an unknown state,
and you should not allow it to continue.
Recalling our earlier discussion regarding subtle differences in the semantics for
changing a process’s group and user IDs, you’ll notice that spc_drop_privileges( ) is
littered with preprocessor conditionals that test for the platform on which the code is
being compiled. For the BSD-derived platforms (Darwin, FreeBSD, NetBSD, and
OpenBSD), dropping privileges involves a simple call to setegid( ) or seteuid( ), followed
by a call to either setgid( ) or setuid( ) if privileges are being permanently
dropped. The setgid( ) and setuid( ) system calls adjust the process’s saved group
and user IDs, respectively, as well as the real group or user ID.
On Linux and Solaris, the setgid( ) and setuid( ) system calls do not alter the process’s
saved group and user IDs in all cases. (In particular, if the effective ID is not
the superuser, the saved ID is not altered; otherwise, it is.). That means that these
calls can’t reliably be used to permanently drop privileges. Instead, setregid( ) and
setreuid( ) are used, which actually simplifies the process except that these two system
calls have different semantics on the BSD-derived platforms.
18 | Chapter 1: Safe Initialization
As discussed above, always drop group privileges before dropping user
privileges; otherwise, group privileges may not be able to be fully
dropped.
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.