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