summaryrefslogtreecommitdiff
path: root/fs/super.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2011-06-03 18:24:58 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2011-06-03 18:24:58 -0400
commit9e1f1de02c2275d7172e18dc4e7c2065777611bf (patch)
tree15e9d202e64275cdbff6ed1d54804da5966d7d8d /fs/super.c
parent1fa7b6a29c61358cc2ca6f64cef4aa0e1a7ca74c (diff)
downloadlwn-9e1f1de02c2275d7172e18dc4e7c2065777611bf.tar.gz
lwn-9e1f1de02c2275d7172e18dc4e7c2065777611bf.zip
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>
Diffstat (limited to 'fs/super.c')
-rw-r--r--fs/super.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/super.c b/fs/super.c
index c75593953c52..ab3d672db0de 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -822,7 +822,7 @@ struct dentry *mount_bdev(struct file_system_type *fs_type,
} else {
char b[BDEVNAME_SIZE];
- s->s_flags = flags;
+ s->s_flags = flags | MS_NOSEC;
s->s_mode = mode;
strlcpy(s->s_id, bdevname(bdev, b), sizeof(s->s_id));
sb_set_blocksize(s, block_size(bdev));