1setfsuid(2)                   System Calls Manual                  setfsuid(2)
2
3
4

NAME

6       setfsuid - set user identity used for filesystem checks
7

LIBRARY

9       Standard C library (libc, -lc)
10

SYNOPSIS

12       #include <sys/fsuid.h>
13
14       [[deprecated]] int setfsuid(uid_t fsuid);
15

DESCRIPTION

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
23       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
31       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
39       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

RETURN VALUE

44       On  both success and failure, this call returns the previous filesystem
45       user ID of the caller.
46

STANDARDS

48       Linux.
49

HISTORY

51       Linux 1.2.
52
53       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
67       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
72   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

BUGS

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

SEE ALSO

90       kill(2), setfsgid(2), capabilities(7), credentials(7)
91
92
93
94Linux man-pages 6.04              2023-03-30                       setfsuid(2)
Impressum