From c3aabf0780a506225b53bfe2b5177dd5dfec093d Mon Sep 17 00:00:00 2001 From: Al Viro Date: Mon, 13 May 2019 12:57:22 -0400 Subject: move mount_capable() further out Call graph of vfs_get_tree(): vfs_fsconfig_locked() # neither kernmount, nor submount do_new_mount() # neither kernmount, nor submount fc_mount() afs_mntpt_do_automount() # submount mount_one_hugetlbfs() # kernmount pid_ns_prepare_proc() # kernmount mq_create_mount() # kernmount vfs_kern_mount() simple_pin_fs() # kernmount vfs_submount() # submount kern_mount() # kernmount init_mount_tree() btrfs_mount() nfs_do_root_mount() The first two need the check (unconditionally). init_mount_tree() is setting rootfs up; any capability checks make zero sense for that one. And btrfs_mount()/ nfs_do_root_mount() have the checks already done in their callers. IOW, we can shift mount_capable() handling into the two callers - one in the normal case of mount(2), another - in fsconfig(2) handling of FSCONFIG_CMD_CREATE. I.e. the syscalls that set a new filesystem up. Signed-off-by: Al Viro --- fs/fsopen.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'fs/fsopen.c') diff --git a/fs/fsopen.c b/fs/fsopen.c index c2891e933ef1..390172772f55 100644 --- a/fs/fsopen.c +++ b/fs/fsopen.c @@ -230,6 +230,8 @@ static int vfs_fsconfig_locked(struct fs_context *fc, int cmd, case FSCONFIG_CMD_CREATE: if (fc->phase != FS_CONTEXT_CREATE_PARAMS) return -EBUSY; + if (!mount_capable(fc)) + return -EPERM; fc->phase = FS_CONTEXT_CREATING; ret = vfs_get_tree(fc); if (ret) -- cgit