1SETUID(3P) POSIX Programmer's Manual SETUID(3P)
2
3
4
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
11
13 setuid — set user ID
14
16 #include <unistd.h>
17
18 int setuid(uid_t uid);
19
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
25 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
30 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
41 EINVAL The value of the uid argument is invalid and not supported by
42 the implementation.
43
44 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
47 The following sections are informative.
48
50 None.
51
53 None.
54
56 The various behaviors of the setuid() and setgid() functions when
57 called by non-privileged processes reflect the behavior of different
58 historical implementations. For portability, it is recommended that new
59 non-privileged applications use the seteuid() and setegid() functions
60 instead.
61
62 The saved set-user-ID capability allows a program to regain the effec‐
63 tive user ID established at the last exec call. Similarly, the saved
64 set-group-ID capability allows a program to regain the effective group
65 ID established at the last exec call. These capabilities are derived
66 from System V. Without them, a program might have to run as superuser
67 in order to perform the same functions, because superuser can write on
68 the user's files. This is a problem because such a program can write on
69 any user's files, and so must be carefully written to emulate the per‐
70 missions of the calling process properly. In System V, these capabili‐
71 ties have traditionally been implemented only via the setuid() and set‐
72 gid() functions for non-privileged processes. The fact that the behav‐
73 ior of those functions was different for privileged processes made them
74 difficult to use. The POSIX.1‐1990 standard defined the setuid() func‐
75 tion to behave differently for privileged and unprivileged users. When
76 the caller had appropriate privileges, the function set the real user
77 ID, effective user ID, and saved set-user ID of the calling process on
78 implementations that supported it. When the caller did not have appro‐
79 priate privileges, the function set only the effective user ID, subject
80 to permission checks. The former use is generally needed for utilities
81 like login and su, which are not conforming applications and thus out‐
82 side the scope of POSIX.1‐2008. These utilities wish to change the user
83 ID irrevocably to a new value, generally that of an unprivileged user.
84 The latter use is needed for conforming applications that are installed
85 with the set-user-ID bit and need to perform operations using the real
86 user ID.
87
88 POSIX.1‐2008 augments the latter functionality with a mandatory feature
89 named _POSIX_SAVED_IDS. This feature permits a set-user-ID application
90 to switch its effective user ID back and forth between the values of
91 its exec-time real user ID and effective user ID. Unfortunately, the
92 POSIX.1‐1990 standard did not permit a conforming application using
93 this feature to work properly when it happened to be executed with
94 (implementation-defined) appropriate privileges. Furthermore, the
95 application did not even have a means to tell whether it had this priv‐
96 ilege. Since the saved set-user-ID feature is quite desirable for
97 applications, as evidenced by the fact that NIST required it in FIPS
98 151‐2, it has been mandated by POSIX.1‐2008. However, there are imple‐
99 mentors who have been reluctant to support it given the limitation
100 described above.
101
102 The 4.3BSD system handles the problem by supporting separate functions:
103 setuid() (which always sets both the real and effective user IDs, like
104 setuid() in POSIX.1‐2008 for privileged users), and seteuid() (which
105 always sets just the effective user ID, like setuid() in POSIX.1‐2008
106 for non-privileged users). This separation of functionality into dis‐
107 tinct functions seems desirable. 4.3BSD does not support the saved set-
108 user-ID feature. It supports similar functionality of switching the
109 effective user ID back and forth via setreuid(), which permits revers‐
110 ing the real and effective user IDs. This model seems less desirable
111 than the saved set-user-ID because the real user ID changes as a side-
112 effect. The current 4.4BSD includes saved effective IDs and uses them
113 for seteuid() and setegid() as described above. The setreuid() and
114 setregid() functions will be deprecated or removed.
115
116 The solution here is:
117
118 * Require that all implementations support the functionality of the
119 saved set-user-ID, which is set by the exec functions and by privi‐
120 leged calls to setuid().
121
122 * Add the seteuid() and setegid() functions as portable alternatives
123 to setuid() and setgid() for non-privileged and privileged pro‐
124 cesses.
125
126 Historical systems have provided two mechanisms for a set-user-ID
127 process to change its effective user ID to be the same as its real user
128 ID in such a way that it could return to the original effective user
129 ID: the use of the setuid() function in the presence of a saved set-
130 user-ID, or the use of the BSD setreuid() function, which was able to
131 swap the real and effective user IDs. The changes included in
132 POSIX.1‐2008 provide a new mechanism using seteuid() in conjunction
133 with a saved set-user-ID. Thus, all implementations with the new
134 seteuid() mechanism will have a saved set-user-ID for each process, and
135 most of the behavior controlled by _POSIX_SAVED_IDS has been changed to
136 agree with the case where the option was defined. The kill() function
137 is an exception. Implementors of the new seteuid() mechanism will gen‐
138 erally be required to maintain compatibility with the older mechanisms
139 previously supported by their systems. However, compatibility with this
140 use of setreuid() and with the _POSIX_SAVED_IDS behavior of kill() is
141 unfortunately complicated. If an implementation with a saved set-user-
142 ID allows a process to use setreuid() to swap its real and effective
143 user IDs, but were to leave the saved set-user-ID unmodified, the
144 process would then have an effective user ID equal to the original real
145 user ID, and both real and saved set-user-ID would be equal to the
146 original effective user ID. In that state, the real user would be
147 unable to kill the process, even though the effective user ID of the
148 process matches that of the real user, if the kill() behavior of
149 _POSIX_SAVED_IDS was used. This is obviously not acceptable. The alter‐
150 native choice, which is used in at least one implementation, is to
151 change the saved set-user-ID to the effective user ID during most calls
152 to setreuid(). The standard developers considered that alternative to
153 be less correct than the retention of the old behavior of kill() in
154 such systems. Current conforming applications shall accommodate either
155 behavior from kill(), and there appears to be no strong reason for
156 kill() to check the saved set-user-ID rather than the effective user
157 ID.
158
160 None.
161
163 exec, getegid(), geteuid(), getgid(), getuid(), setegid(), seteuid(),
164 setgid(), setregid(), setreuid()
165
166 The Base Definitions volume of POSIX.1‐2008, <sys_types.h>, <unistd.h>
167
169 Portions of this text are reprinted and reproduced in electronic form
170 from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
171 -- Portable Operating System Interface (POSIX), The Open Group Base
172 Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
173 cal and Electronics Engineers, Inc and The Open Group. (This is
174 POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
175 event of any discrepancy between this version and the original IEEE and
176 The Open Group Standard, the original IEEE and The Open Group Standard
177 is the referee document. The original Standard can be obtained online
178 at http://www.unix.org/online.html .
179
180 Any typographical or formatting errors that appear in this page are
181 most likely to have been introduced during the conversion of the source
182 files to man page format. To report such errors, see https://www.ker‐
183 nel.org/doc/man-pages/reporting_bugs.html .
184
185
186
187IEEE/The Open Group 2013 SETUID(3P)