linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Christoph Hellwig <hch@lst.de>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Christian Brauner <christian.brauner@ubuntu.com>,
	Christoph Hellwig <hch@infradead.org>
Subject: [PATCH 21/24] btrfs/ioctl: allow idmapped BTRFS_IOC_INO_LOOKUP_USER ioctl
Date: Tue, 13 Jul 2021 13:13:41 +0200	[thread overview]
Message-ID: <20210713111344.1149376-22-brauner@kernel.org> (raw)
In-Reply-To: <20210713111344.1149376-1-brauner@kernel.org>

From: Christian Brauner <christian.brauner@ubuntu.com>

The BTRFS_IOC_INO_LOOKUP_USER is an unprivileged version of the
BTRFS_IOC_INO_LOOKUP ioctl and has the following restrictions. The main
difference between the two is that BTRFS_IOC_INO_LOOKUP is filesystem wide
operation wheres BTRFS_IOC_INO_LOOKUP_USER is scoped beneath the file
descriptor passed with the ioctl. Specifically, BTRFS_IOC_INO_LOOKUP_USER must
adhere to the following restrictions:
- The caller must be privileged over each inode of each path component for the
  path they are trying to lookup.
- The path for the subvolume the caller is trying to lookup must be reachable
  from the inode associated with the file descriptor passed with the ioctl.
The second condition makes it possible to scope the lookup of the path to the
mount identified by the file descriptor passed with the ioctl. This allows us
to enable this ioctl on idmapped mounts.

Specifically, this is possible because all child subvolumes of a parent
subvolume are reachable when the parent subvolume is mounted. So if the user
had access to open the parent subvolume or has been given the fd then they can
lookup the path if they had access to it provided they were privileged over
each path component.

Note, the BTRFS_IOC_INO_LOOKUP_USER ioctl allows a user to learn the path and
name of a subvolume even though they would otherwise be restricted from doing
so via regular vfs-based lookup.
So think about a parent subvolume with multiple child subvolumes. Someone could
mount he parent subvolume and restrict access to the child subvolumes by
overmounting them with empty directories. At this point the user can't traverse
the child subvolumes and they can't open files in the child subvolumes.
However, they can still learn the path of child subvolumes as long as they have
access to the parent subvolume by using the BTRFS_IOC_INO_LOOKUP_USER ioctl.

The underlying assumption here is that it's ok that the lookup ioctls can't
really take mounts into account other than the original mount the fd belongs to
during lookup. Since this assumption is baked into the original
BTRFS_IOC_INO_LOOKUP_USER ioctl we can extend it to idmapped mounts.

Cc: Chris Mason <clm@fb.com>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
---
 fs/btrfs/ioctl.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 8c1ca9f05f4f..f56b4e159099 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2439,7 +2439,8 @@ static noinline int btrfs_search_path_in_tree(struct btrfs_fs_info *info,
 	return ret;
 }
 
-static int btrfs_search_path_in_tree_user(struct inode *inode,
+static int btrfs_search_path_in_tree_user(struct user_namespace *mnt_userns,
+				struct inode *inode,
 				struct btrfs_ioctl_ino_lookup_user_args *args)
 {
 	struct btrfs_fs_info *fs_info = BTRFS_I(inode)->root->fs_info;
@@ -2537,7 +2538,7 @@ static int btrfs_search_path_in_tree_user(struct inode *inode,
 				ret = PTR_ERR(temp_inode);
 				goto out_put;
 			}
-			ret = inode_permission(&init_user_ns, temp_inode,
+			ret = inode_permission(mnt_userns, temp_inode,
 					       MAY_READ | MAY_EXEC);
 			iput(temp_inode);
 			if (ret) {
@@ -2679,7 +2680,7 @@ static int btrfs_ioctl_ino_lookup_user(struct file *file, void __user *argp)
 		return -EACCES;
 	}
 
-	ret = btrfs_search_path_in_tree_user(inode, args);
+	ret = btrfs_search_path_in_tree_user(file_mnt_user_ns(file), inode, args);
 
 	if (ret == 0 && copy_to_user(argp, args, sizeof(*args)))
 		ret = -EFAULT;
-- 
2.30.2


  parent reply	other threads:[~2021-07-13 11:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 11:13 [PATCH 00/24] btrfs: support idmapped mounts Christian Brauner
2021-07-13 11:13 ` [PATCH 01/24] namei: handle mappings in lookup_one_len() Christian Brauner
2021-07-13 13:32   ` Al Viro
2021-07-13 13:41     ` Christian Brauner
2021-07-13 11:13 ` [PATCH 02/24] namei: handle mappings in lookup_one_len_unlocked() Christian Brauner
2021-07-13 13:34   ` Al Viro
2021-07-13 11:13 ` [PATCH 03/24] namei: handle mappings in lookup_positive_unlocked() Christian Brauner
2021-07-13 11:13 ` [PATCH 04/24] namei: handle mappings in try_lookup_one_len() Christian Brauner
2021-07-13 11:13 ` [PATCH 05/24] btrfs/inode: handle idmaps in btrfs_new_inode() Christian Brauner
2021-07-13 11:13 ` [PATCH 06/24] btrfs/inode: allow idmapped rename iop Christian Brauner
2021-07-13 11:13 ` [PATCH 07/24] btrfs/inode: allow idmapped getattr iop Christian Brauner
2021-07-13 11:13 ` [PATCH 08/24] btrfs/inode: allow idmapped mknod iop Christian Brauner
2021-07-13 11:13 ` [PATCH 09/24] btrfs/inode: allow idmapped create iop Christian Brauner
2021-07-13 11:13 ` [PATCH 10/24] btrfs/inode: allow idmapped mkdir iop Christian Brauner
2021-07-13 11:13 ` [PATCH 11/24] btrfs/inode: allow idmapped symlink iop Christian Brauner
2021-07-13 11:13 ` [PATCH 12/24] btrfs/inode: allow idmapped tmpfile iop Christian Brauner
2021-07-13 11:13 ` [PATCH 13/24] btrfs/inode: allow idmapped setattr iop Christian Brauner
2021-07-13 11:13 ` [PATCH 14/24] btrfs/inode: allow idmapped permission iop Christian Brauner
2021-07-13 11:13 ` [PATCH 15/24] btrfs/ioctl: check whether fs{g,u}id are mapped during subvolume creation Christian Brauner
2021-07-13 11:13 ` [PATCH 16/24] btrfs/inode: allow idmapped BTRFS_IOC_{SNAP,SUBVOL}_CREATE{_V2} ioctl Christian Brauner
2021-07-13 11:13 ` [PATCH 17/24] btrfs/ioctl: allow idmapped BTRFS_IOC_SNAP_DESTROY{_V2} ioctl Christian Brauner
2021-07-14  1:00   ` Qu Wenruo
2021-07-13 11:13 ` [PATCH 18/24] btrfs/ioctl: relax restrictions for BTRFS_IOC_SNAP_DESTROY_V2 with subvolids Christian Brauner
2021-07-13 11:13 ` [PATCH 19/24] btrfs/ioctl: allow idmapped BTRFS_IOC_SET_RECEIVED_SUBVOL{_32} ioctl Christian Brauner
2021-07-13 11:13 ` [PATCH 20/24] btrfs/ioctl: allow idmapped BTRFS_IOC_SUBVOL_SETFLAGS ioctl Christian Brauner
2021-07-13 11:13 ` Christian Brauner [this message]
2021-07-13 11:13 ` [PATCH 22/24] btrfs/acl: handle idmapped mounts Christian Brauner
2021-07-13 11:13 ` [PATCH 23/24] btrfs/super: allow idmapped btrfs Christian Brauner
2021-07-13 11:13 ` [PATCH 24/24] btrfs/242: introduce btrfs specific idmapped mounts tests Christian Brauner
2021-07-13 11:23 ` [PATCH 00/24] btrfs: support idmapped mounts Qu Wenruo
2021-07-13 13:59   ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210713111344.1149376-22-brauner@kernel.org \
    --to=brauner@kernel.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).