1SETUID(3P) POSIX Programmer's Manual SETUID(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 setuid - set user ID
13
15 #include <unistd.h>
16 int setuid(uid_t uid);
18
21 If the process has appropriate privileges, setuid() shall set the real
22 user ID, effective user ID, and the saved set-user-ID of the calling
23 process to uid.
24 If the process does not have appropriate privileges, but uid is equal
26 to the real user ID or the saved set-user-ID, setuid() shall set the
27 effective user ID to uid; the real user ID and saved set-user-ID shall
28 remain unchanged.
29 The setuid() function shall not affect the supplementary group list in
31 any way.
32
34 Upon successful completion, 0 shall be returned. Otherwise, -1 shall be
35 returned and errno set to indicate the error.
36
38 The setuid() function shall fail, return -1, and set errno to the cor‐
39 responding value if one or more of the following are true:
40 EINVAL The value of the uid argument is invalid and not supported by
42 the implementation.
43 EPERM The process does not have appropriate privileges and uid does
45 not match the real user ID or the saved set-user-ID.
46 The following sections are informative.
49
51 None.
52
54 None.
55
57 The various behaviors of the setuid() and setgid() functions when
58 called by non-privileged processes reflect the behavior of different
59 historical implementations. For portability, it is recommended that new
60 non-privileged applications use the seteuid() and setegid() functions
61 instead.
62 The saved set-user-ID capability allows a program to regain the effec‐
64 tive user ID established at the last exec call. Similarly, the saved
65 set-group-ID capability allows a program to regain the effective group
66 ID established at the last exec call. These capabilities are derived
67 from System V. Without them, a program might have to run as superuser
68 in order to perform the same functions, because superuser can write on
69 the user's files. This is a problem because such a program can write on
70 any user's files, and so must be carefully written to emulate the per‐
71 missions of the calling process properly. In System V, these capabili‐
72 ties have traditionally been implemented only via the setuid() and set‐
73 gid() functions for non-privileged processes. The fact that the behav‐
74 ior of those functions was different for privileged processes made them
75 difficult to use. The POSIX.1-1990 standard defined the setuid() func‐
76 tion to behave differently for privileged and unprivileged users. When
77 the caller had the appropriate privilege, the function set the calling
78 process' real user ID, effective user ID, and saved set-user ID on
79 implementations that supported it. When the caller did not have the
80 appropriate privilege, the function set only the effective user ID,
81 subject to permission checks. The former use is generally needed for
82 utilities like login and su, which are not conforming applications and
83 thus outside the scope of IEEE Std 1003.1-2001. These utilities wish
84 to change the user ID irrevocably to a new value, generally that of an
85 unprivileged user. The latter use is needed for conforming applica‐
86 tions that are installed with the set-user-ID bit and need to perform
87 operations using the real user ID.
88 IEEE Std 1003.1-2001 augments the latter functionality with a mandatory
90 feature named _POSIX_SAVED_IDS. This feature permits a set-user-ID
91 application to switch its effective user ID back and forth between the
92 values of its exec-time real user ID and effective user ID. Unfortu‐
93 nately, the POSIX.1-1990 standard did not permit a conforming applica‐
94 tion using this feature to work properly when it happened to be exe‐
95 cuted with the (implementation-defined) appropriate privilege. Further‐
96 more, the application did not even have a means to tell whether it had
97 this privilege. Since the saved set-user-ID feature is quite desirable
98 for applications, as evidenced by the fact that NIST required it in
99 FIPS 151-2, it has been mandated by IEEE Std 1003.1-2001. However,
100 there are implementors who have been reluctant to support it given the
101 limitation described above.
102 The 4.3BSD system handles the problem by supporting separate functions:
104 setuid() (which always sets both the real and effective user IDs, like
105 setuid() in IEEE Std 1003.1-2001 for privileged users), and seteuid()
106 (which always sets just the effective user ID, like setuid() in
107 IEEE Std 1003.1-2001 for non-privileged users). This separation of
108 functionality into distinct functions seems desirable. 4.3BSD does not
109 support the saved set-user-ID feature. It supports similar functional‐
110 ity of switching the effective user ID back and forth via setreuid(),
111 which permits reversing the real and effective user IDs. This model
112 seems less desirable than the saved set-user-ID because the real user
113 ID changes as a side effect. The current 4.4BSD includes saved effec‐
114 tive IDs and uses them for seteuid() and setegid() as described above.
115 The setreuid() and setregid() functions will be deprecated or removed.
116 The solution here is:
118 * Require that all implementations support the functionality of the
120 saved set-user-ID, which is set by the exec functions and by privi‐
121 leged calls to setuid().
122 * Add the seteuid() and setegid() functions as portable alternatives
124 to setuid() and setgid() for non-privileged and privileged pro‐
125 cesses.
126 Historical systems have provided two mechanisms for a set-user-ID
128 process to change its effective user ID to be the same as its real user
129 ID in such a way that it could return to the original effective user
130 ID: the use of the setuid() function in the presence of a saved set-
131 user-ID, or the use of the BSD setreuid() function, which was able to
132 swap the real and effective user IDs. The changes included in
133 IEEE Std 1003.1-2001 provide a new mechanism using seteuid() in con‐
134 junction with a saved set-user-ID. Thus, all implementations with the
135 new seteuid() mechanism will have a saved set-user-ID for each process,
136 and most of the behavior controlled by _POSIX_SAVED_IDS has been
137 changed to agree with the case where the option was defined. The kill()
138 function is an exception. Implementors of the new seteuid() mechanism
139 will generally be required to maintain compatibility with the older
140 mechanisms previously supported by their systems. However, compatibil‐
141 ity with this use of setreuid() and with the _POSIX_SAVED_IDS behavior
142 of kill() is unfortunately complicated. If an implementation with a
143 saved set-user-ID allows a process to use setreuid() to swap its real
144 and effective user IDs, but were to leave the saved set-user-ID unmodi‐
145 fied, the process would then have an effective user ID equal to the
146 original real user ID, and both real and saved set-user-ID would be
147 equal to the original effective user ID. In that state, the real user
148 would be unable to kill the process, even though the effective user ID
149 of the process matches that of the real user, if the kill() behavior of
150 _POSIX_SAVED_IDS was used. This is obviously not acceptable. The alter‐
151 native choice, which is used in at least one implementation, is to
152 change the saved set-user-ID to the effective user ID during most calls
153 to setreuid(). The standard developers considered that alternative to
154 be less correct than the retention of the old behavior of kill() in
155 such systems. Current conforming applications shall accommodate either
156 behavior from kill(), and there appears to be no strong reason for
157 kill() to check the saved set-user-ID rather than the effective user
158 ID.
159
161 None.
162
164 exec(), getegid(), geteuid(), getgid(), getuid(), setegid(), seteuid(),
165 setgid(), setregid(), setreuid(), the Base Definitions volume of
166 IEEE Std 1003.1-2001, <sys/types.h>, <unistd.h>
167
169 Portions of this text are reprinted and reproduced in electronic form
170 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
171 -- Portable Operating System Interface (POSIX), The Open Group Base
172 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
173 Electrical and Electronics Engineers, Inc and The Open Group. In the
174 event of any discrepancy between this version and the original IEEE and
175 The Open Group Standard, the original IEEE and The Open Group Standard
176 is the referee document. The original Standard can be obtained online
177 at http://www.opengroup.org/unix/online.html .
178IEEE/The Open Group 2003 SETUID(3P)