1setfsuid(2) System Calls Manual setfsuid(2)
2
6 setfsuid - set user identity used for filesystem checks
7
9 Standard C library (libc, -lc)
10
12 #include <sys/fsuid.h>
13 [[deprecated]] int setfsuid(uid_t fsuid);
15
17 On Linux, a process has both a filesystem user ID and an effective user
18 ID. The (Linux-specific) filesystem user ID is used for permissions
19 checking when accessing filesystem objects, while the effective user ID
20 is used for various other kinds of permissions checks (see creden‐
21 tials(7)).
22 Normally, the value of the process's filesystem user ID is the same as
24 the value of its effective user ID. This is so, because whenever a
25 process's effective user ID is changed, the kernel also changes the
26 filesystem user ID to be the same as the new value of the effective
27 user ID. A process can cause the value of its filesystem user ID to
28 diverge from its effective user ID by using setfsuid() to change its
29 filesystem user ID to the value given in fsuid.
30 Explicit calls to setfsuid() and setfsgid(2) are (were) usually used
32 only by programs such as the Linux NFS server that need to change what
33 user and group ID is used for file access without a corresponding
34 change in the real and effective user and group IDs. A change in the
35 normal user IDs for a program such as the NFS server is (was) a secu‐
36 rity hole that can expose it to unwanted signals. (However, this issue
37 is historical; see below.)
38 setfsuid() will succeed only if the caller is the superuser or if fsuid
40 matches either the caller's real user ID, effective user ID, saved set-
41 user-ID, or current filesystem user ID.
42
44 On both success and failure, this call returns the previous filesystem
45 user ID of the caller.
46
48 Linux.
49
51 Linux 1.2.
52 At the time when this system call was introduced, one process could
54 send a signal to another process with the same effective user ID. This
55 meant that if a privileged process changed its effective user ID for
56 the purpose of file permission checking, then it could become vulnera‐
57 ble to receiving signals sent by another (unprivileged) process with
58 the same user ID. The filesystem user ID attribute was thus added to
59 allow a process to change its user ID for the purposes of file permis‐
60 sion checking without at the same time becoming vulnerable to receiving
61 unwanted signals. Since Linux 2.0, signal permission handling is dif‐
62 ferent (see kill(2)), with the result that a process can change its ef‐
63 fective user ID without being vulnerable to receiving signals from un‐
64 wanted processes. Thus, setfsuid() is nowadays unneeded and should be
65 avoided in new applications (likewise for setfsgid(2)).
66 The original Linux setfsuid() system call supported only 16-bit user
68 IDs. Subsequently, Linux 2.4 added setfsuid32() supporting 32-bit IDs.
69 The glibc setfsuid() wrapper function transparently deals with the
70 variation across kernel versions.
71 C library/kernel differences
73 In glibc 2.15 and earlier, when the wrapper for this system call deter‐
74 mines that the argument can't be passed to the kernel without integer
75 truncation (because the kernel is old and does not support 32-bit user
76 IDs), it will return -1 and set errno to EINVAL without attempting the
77 system call.
78
80 No error indications of any kind are returned to the caller, and the
81 fact that both successful and unsuccessful calls return the same value
82 makes it impossible to directly determine whether the call succeeded or
83 failed. Instead, the caller must resort to looking at the return value
84 from a further call such as setfsuid(-1) (which will always fail), in
85 order to determine if a preceding call to setfsuid() changed the
86 filesystem user ID. At the very least, EPERM should be returned when
87 the call fails (because the caller lacks the CAP_SETUID capability).
88
90 kill(2), setfsgid(2), capabilities(7), credentials(7)
91Linux man-pages 6.05 2023-03-30 setfsuid(2)