summaryrefslogtreecommitdiffstats
path: root/ipc
diff options
context:
space:
mode:
authorChristian Brauner <christian.brauner@ubuntu.com>2022-05-10 11:58:40 +0200
committerChristian Brauner (Microsoft) <brauner@kernel.org>2022-05-12 10:12:00 +0200
commite1bbcd277a53e08d619ffeec56c5c9287f2bf42f (patch)
tree537a1fa8102948099706765d438e20d6ecf4473a /ipc
parentccbd0c991985afc53670e2b01840517922fc30e4 (diff)
downloadlinux-stable-e1bbcd277a53e08d619ffeec56c5c9287f2bf42f.tar.gz
linux-stable-e1bbcd277a53e08d619ffeec56c5c9287f2bf42f.tar.bz2
linux-stable-e1bbcd277a53e08d619ffeec56c5c9287f2bf42f.zip
fs: hold writers when changing mount's idmapping
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: Christian Brauner (Microsoft) <brauner@kernel.org>
Diffstat (limited to 'ipc')
0 files changed, 0 insertions, 0 deletions