diff options
| author | Al Viro <viro@zeniv.linux.org.uk> | 2011-06-04 00:24:58 +0200 |
|---|---|---|
| committer | Al Viro <viro@zeniv.linux.org.uk> | 2011-06-04 00:24:58 +0200 |
| commit | 9e1f1de02c2275d7172e18dc4e7c2065777611bf (patch) | |
| tree | 15e9d202e64275cdbff6ed1d54804da5966d7d8d /fs/super.c | |
| parent | Revert "mm: fail GFP_DMA allocations when ZONE_DMA is not configured" (diff) | |
| download | linux-9e1f1de02c2275d7172e18dc4e7c2065777611bf.tar.xz linux-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.c | 2 |
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)); |