setfsuid() and access() syscall

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

the access() syscall (to find out if the user has permission to do something on file) does not seem to reflect the setfsuid() syscall. There are 2 conflicting pieces of information:

- kernel/sys.c:
/*
* "setfsuid()" sets the fsuid - the uid used for filesystem checks. This
* is used for "access()" and for the NFS daemon (letting nfsd stay at
* whatever uid it wants to). It normally shadows "euid", except when
* explicitly set by setfsuid() or for access..
*/
- fs/namei.c
/*
* access() needs to use the real uid/gid, not the effective uid/gid.
* We do this by temporarily clearing all FS-related capabilities and
* switching the fsuid/fsgid around to the real ones.
*/

The resulting behaviour (2.6.18, 2.6.28, source code for 2.6.30 seems to be the same) seems to be that access() is dependent on uid, not fsuid - this seems to me to be a bug, which unfortunately somewhat inhibits multithreaded file servers that want to use access() e.g. for ACL checks. Is there some reason why it is implemented the way it is as it looks like an intention?

Best regards
Ondrej Palkovsky

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux