• A
    more conservative S_NOSEC handling · 9e1f1de0
    Al Viro 提交于
    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: NAl Viro <viro@zeniv.linux.org.uk>
    9e1f1de0
inode.c 28.1 KB