Al Viro 9e1f1de02c more conservative S_NOSEC handling ... Caching "we have already removed suid/caps" was overenthusiastic as merged. On network filesystems we might have had suid/caps set on another client, silently picked by this client on revalidate, all of that *without* clearing the S_NOSEC flag. AFAICS, the only reasonably sane way to deal with that is * new superblock flag; unless set, S_NOSEC is not going to be set. * local block filesystems set it in their ->mount() (more accurately, mount_bdev() does, so does btrfs ->mount(), users of mount_bdev() other than local block ones clear it) * if any network filesystem (or a cluster one) wants to use S_NOSEC, it'll need to set MS_NOSEC in sb->s_flags *AND* take care to clear S_NOSEC when inode attribute changes are picked from other clients. It's not an earth-shattering hole (anybody that can set suid on another client will almost certainly be able to write to the file before doing that anyway), but it's a bug that needs fixing. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>		2011-06-03 18:24:58 -04:00
..
control.c
cuse.c
dev.c
dir.c	fuse: remove unnecessary dentry_unhash on rmdir, dir rename	2011-05-28 01:02:53 -04:00
file.c
fuse_i.h
inode.c	more conservative S_NOSEC handling	2011-06-03 18:24:58 -04:00
Kconfig
Makefile