summary refs log tree commit diff
path: root/fs/ecryptfs
diff options
context:
space:
mode:
authorChristian Brauner <christian.brauner@ubuntu.com>2021-01-21 14:19:31 +0100
committerChristian Brauner <christian.brauner@ubuntu.com>2021-01-24 14:27:17 +0100
commitba73d98745be1c10dc3cce68e8d7b95012d07d05 (patch)
tree6b88b691fba3c40f8d1ad0c4bda7c98a376bd529 /fs/ecryptfs
parent0d56a4518d5eaf595a24ab2202e171330bb2ed72 (diff)
downloadlinux-ba73d98745be1c10dc3cce68e8d7b95012d07d05.tar.gz
namei: handle idmapped mounts in may_*() helpers
The may_follow_link(), may_linkat(), may_lookup(), may_open(),
may_o_create(), may_create_in_sticky(), may_delete(), and may_create()
helpers determine whether the caller is privileged enough to perform the
associated operations. Let them handle idmapped mounts by mapping the
inode or fsids according to the mount's user namespace. Afterwards the
checks are identical to non-idmapped inodes. The patch takes care to
retrieve the mount's user namespace right before performing permission
checks and passing it down into the fileystem so the user namespace
can't change in between by someone idmapping a mount that is currently
not idmapped. If the initial user namespace is passed nothing changes so
non-idmapped mounts will see identical behavior as before.

Link: https://lore.kernel.org/r/20210121131959.646623-13-christian.brauner@ubuntu.com
Cc: Christoph Hellwig <hch@lst.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Diffstat (limited to 'fs/ecryptfs')
0 files changed, 0 insertions, 0 deletions