NAME
setuid — set user
ID
SYNOPSIS
#include
<unistd.h>
int setuid(uid_t uid);
DESCRIPTION
If the process has appropriate privileges,
setuid () shall set the real user ID, effective user
ID, and the saved set-user-ID of the calling process to
uid.
If the process does not have appropriate privileges, but
uid is equal to the real user ID or the saved set-user-ID,
setuid () shall set the effective user ID to
uid; the real user ID and saved set-user-ID shall remain
unchanged.
The setuid () function shall not affect
the supplementary group list in any way.
RETURN VALUE
Upon successful completion, 0 shall be returned. Otherwise, -1 shall be returned and errno set to indicate the error.
ERRORS
The setuid () function shall fail, return
-1, and set errno to the corresponding value if one or
more of the following are true:
EXAMPLES
None.
APPLICATION USAGE
None.
RATIONALE
The various behaviors of the setuid () and
setgid(3) functions when called by non-privileged
processes reflect the behavior of different historical implementations. For
portability, it is recommended that new non-privileged applications use the
seteuid(3) and setegid(3) functions
instead.
The saved set-user-ID capability allows a program to
regain the effective user ID established at the last exec
call. Similarly, the saved set-group-ID capability allows a program to
regain the effective group ID established at the last exec
call. These capabilities are derived from System V. Without them, a program
might have to run as superuser in order to perform the same functions,
because superuser can write on the user's files. This is a problem because
such a program can write on any user's files, and so must be carefully
written to emulate the permissions of the calling process properly. In
System V, these capabilities have traditionally been implemented only via
the setuid () and setgid(3)
functions for non-privileged processes. The fact that the behavior of those
functions was different for privileged processes made them difficult to use.
The POSIX.1-1990 standard defined the setuid ()
function to behave differently for privileged and unprivileged users. When
the caller had the appropriate privilege, the function set the calling
process' real user ID, effective user ID, and saved set-user ID on
implementations that supported it. When the caller did not have the
appropriate privilege, the function set only the effective user ID, subject
to permission checks. The former use is generally needed for utilities like
login and
su, which are
not conforming applications and thus outside the scope of
IEEE Std 1003.1-2001 (“POSIX.1”).
These utilities wish to change the user ID irrevocably to a new value,
generally that of an unprivileged user. The latter use is needed for
conforming applications that are installed with the set-user-ID bit and need
to perform operations using the real user ID.
IEEE Std 1003.1-2001 (“POSIX.1”) augments the latter functionality with a mandatory feature named _POSIX_SAVED_IDS. This feature permits a set-user-ID application to switch its effective user ID back and forth between the values of its exec -time real user ID and effective user ID. Unfortunately, the POSIX.1-1990 standard did not permit a conforming application using this feature to work properly when it happened to be executed with the (implementation-defined) appropriate privilege. Furthermore, the application did not even have a means to tell whether it had this privilege. Since the saved set-user-ID feature is quite desirable for applications, as evidenced by the fact that NIST required it in FIPS 151-2, it has been mandated by IEEE Std 1003.1-2001 (“POSIX.1”). However, there are implementors who have been reluctant to support it given the limitation described above.
The 4.3BSD system handles the problem by supporting separate
functions: setuid () (which always sets both the
real and effective user IDs, like setuid () in
IEEE Std 1003.1-2001 (“POSIX.1”) for
privileged users), and seteuid(3) (which always sets just
the effective user ID, like setuid () in
IEEE Std 1003.1-2001 (“POSIX.1”) for
non-privileged users). This separation of functionality into distinct
functions seems desirable. 4.3BSD does not support the saved set-user-ID
feature. It supports similar functionality of switching the effective user
ID back and forth via setreuid(3), which permits reversing
the real and effective user IDs. This model seems less desirable than the
saved set-user-ID because the real user ID changes as a side effect. The
current 4.4BSD includes saved effective IDs and uses them for
seteuid(3) and setegid(3) as described
above. The setreuid(3) and setregid(3)
functions will be deprecated or removed.
The solution here is:
- Require that all implementations support the functionality of the saved
set-user-ID, which is set by the exec functions and by
privileged calls to
setuid(). - Add the seteuid(3) and setegid(3)
functions as portable alternatives to
setuid() and setgid(3) for non-privileged and privileged processes.
Historical systems have provided two mechanisms for a set-user-ID
process to change its effective user ID to be the same as its real user ID
in such a way that it could return to the original effective user ID: the
use of the setuid () function in the presence of a
saved set-user-ID, or the use of the BSD setreuid(3)
function, which was able to swap the real and effective user IDs. The
changes included in IEEE Std 1003.1-2001
(“POSIX.1”) provide a new mechanism using
seteuid(3) in conjunction with a saved set-user-ID. Thus,
all implementations with the new seteuid(3) mechanism will
have a saved set-user-ID for each process, and most of the behavior
controlled by _POSIX_SAVED_IDS has been changed to agree with the case where
the option was defined. The kill(3) function is an
exception. Implementors of the new seteuid(3) mechanism
will generally be required to maintain compatibility with the older
mechanisms previously supported by their systems. However, compatibility
with this use of setreuid(3) and with the _POSIX_SAVED_IDS
behavior of kill(3) is unfortunately complicated. If an
implementation with a saved set-user-ID allows a process to use
setreuid(3) to swap its real and effective user IDs, but
were to leave the saved set-user-ID unmodified, the process would then have
an effective user ID equal to the original real user ID, and both real and
saved set-user-ID would be equal to the original effective user ID. In that
state, the real user would be unable to kill the process, even though the
effective user ID of the process matches that of the real user, if the
kill(3) behavior of _POSIX_SAVED_IDS was used. This is
obviously not acceptable. The alternative choice, which is used in at least
one implementation, is to change the saved set-user-ID to the effective user
ID during most calls to setreuid(3). The standard
developers considered that alternative to be less correct than the retention
of the old behavior of kill(3) in such systems. Current
conforming applications shall accommodate either behavior from
kill(3), and there appears to be no strong reason for
kill(3) to check the saved set-user-ID rather than the
effective user ID.
FUTURE DIRECTIONS
None.
SEE ALSO
exec(3) , getegid(3) , geteuid(3) , getgid(3) , getuid(3) , setegid(3) , seteuid(3) , setgid(3) , setregid(3) , setreuid(3) , the Base Definitions volume of IEEE Std 1003.1-2001 (“POSIX.1”), <sys/types.h>, <unistd.h>
CHANGE HISTORY
First released in Issue 1. Derived from Issue 1 of the SVID.
Issue 6
In the SYNOPSIS, the optional include of the <sys/types.h> header is removed.
The following new requirements on POSIX implementations derive from alignment with the Single UNIX Specification:
- The requirement to include <sys/types.h> has been removed. Although <sys/types.h> was required for conforming implementations of previous POSIX specifications, it was not required for UNIX applications.
- The functionality associated with _POSIX_SAVED_IDS is now mandatory. This is a FIPS requirement.
The following changes were made to align with the IEEE P1003.1a draft standard:
- The effects of
setuid() in processes without appropriate privileges are changed. - A requirement that the supplementary group list is not affected is added.
End of informative text. footer end