• Christian Brauner's avatar
    fs: hold writers when changing mount's idmapping · e1bbcd27
    Christian Brauner authored
    Hold writers when changing a mount's idmapping to make it more robust.
    
    The vfs layer takes care to retrieve the idmapping of a mount once
    ensuring that the idmapping used for vfs permission checking is
    identical to the idmapping passed down to the filesystem.
    
    For ioctl codepaths the filesystem itself is responsible for taking the
    idmapping into account if they need to. While all filesystems with
    FS_ALLOW_IDMAP raised take the same precautions as the vfs we should
    enforce it explicitly by making sure there are no active writers on the
    relevant mount while changing the idmapping.
    
    This is similar to turning a mount ro with the difference that in
    contrast to turning a mount ro changing the idmapping can only ever be
    done once while a mount can transition between ro and rw as much as it
    wants.
    
    This is a minor user-visible change. But it is extremely unlikely to
    matter. The caller must've created a detached mount via OPEN_TREE_CLONE
    and then handed that O_PATH fd to another process or thread which then
    must've gotten a writable fd for that mount and started creating files
    in there while the caller is still changing mount properties. While not
    impossible it will be an extremely rare corner-case and should in
    general be considered a bug in the application. Consider making a mount
    MOUNT_ATTR_NOEXEC or MOUNT_ATTR_NODEV while allowing someone else to
    perform lookups or exec'ing in parallel by handing them a copy of the
    OPEN_TREE_CLONE fd or another fd beneath that mount.
    
    Link: https://lore.kernel.org/r/20220510095840.152264-1-brauner@kernel.org
    Cc: Seth Forshee <seth.forshee@digitalocean.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: default avatarChristian Brauner (Microsoft) <brauner@kernel.org>
    e1bbcd27
namespace.c 114 KB