From patchwork Tue Mar 20 06:45:37 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Misono Tomohiro X-Patchwork-Id: 10296587 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AE08E602B3 for ; Tue, 20 Mar 2018 06:46:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9DD1D29173 for ; Tue, 20 Mar 2018 06:46:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9254A29189; Tue, 20 Mar 2018 06:46:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F047129173 for ; Tue, 20 Mar 2018 06:46:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751319AbeCTGqK (ORCPT ); Tue, 20 Mar 2018 02:46:10 -0400 Received: from mgwym02.jp.fujitsu.com ([211.128.242.41]:62029 "EHLO mgwym02.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750888AbeCTGqJ (ORCPT ); Tue, 20 Mar 2018 02:46:09 -0400 Received: from yt-mxq.gw.nic.fujitsu.com (unknown [192.168.229.66]) by mgwym02.jp.fujitsu.com with smtp id 2d48_0d18_00fb4fd6_b4c8_4e9b_80be_cf3119ce444f; Tue, 20 Mar 2018 15:46:03 +0900 Received: from g01jpfmpwkw02.exch.g01.fujitsu.local (g01jpfmpwkw02.exch.g01.fujitsu.local [10.0.193.56]) by yt-mxq.gw.nic.fujitsu.com (Postfix) with ESMTP id E4B6BAC00DB for ; Tue, 20 Mar 2018 15:46:03 +0900 (JST) Received: from G01JPEXCHKW16.g01.fujitsu.local (G01JPEXCHKW16.g01.fujitsu.local [10.0.194.55]) by g01jpfmpwkw02.exch.g01.fujitsu.local (Postfix) with ESMTP id 08AA13284A2 for ; Tue, 20 Mar 2018 15:46:03 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v2.5.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20170217-enc X-SHieldMailCheckerMailID: 73c251b940cb4a27ba1af88f961cff29 To: linux-btrfs From: "Misono, Tomohiro" Subject: [PATCH] btrfs: Allow non-privileged user to delete empty subvolume by default Message-ID: <5164078e-4e15-d6df-7356-fa4f5d70a2db@jp.fujitsu.com> Date: Tue, 20 Mar 2018 15:45:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Language: en-US X-SecurityPolicyCheck-GC: OK by FENCE-Mail X-TM-AS-MML: disable Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Deletion of subvolume by non-privileged user is completely restricted by default because we can delete a subvolume even if it is not empty and may cause data loss. In other words, when user_subvol_rm_allowed mount option is used, a user can delete a subvolume containing the directory which cannot be deleted directly by the user. However, there should be no harm to allow users to delete empty subvolumes when rmdir(2) would have been allowed if they were normal directories. This patch allows deletion of empty subvolume by default. Note that user_subvol_rm_allowed option requires write+exec permission of the subvolume to be deleted, but they are not required for empty subvolume. The comment in the code is also updated accordingly. Signed-off-by: Tomohiro Misono --- fs/btrfs/ioctl.c | 55 +++++++++++++++++++++++++++++++------------------------ 1 file changed, 31 insertions(+), 24 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 111ee282b777..838406a7a7f5 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2366,36 +2366,43 @@ static noinline int btrfs_ioctl_snap_destroy(struct file *file, dest = BTRFS_I(inode)->root; if (!capable(CAP_SYS_ADMIN)) { /* - * Regular user. Only allow this with a special mount - * option, when the user has write+exec access to the - * subvol root, and when rmdir(2) would have been - * allowed. + * By default, regular user is only allowed to delete + * empty subvols when rmdir(2) would have been allowed + * if they were normal directories. * - * Note that this is _not_ check that the subvol is - * empty or doesn't contain data that we wouldn't + * If the mount option 'user_subvol_rm_allowed' is set, + * it allows users to delete non-empty subvols when the + * user has write+exec access to the subvol root and when + * rmdir(2) would have been allowed (except the emptiness + * check). + * + * Note that this option does _not_ check that if the subvol + * is empty or doesn't contain data that the user wouldn't * otherwise be able to delete. * - * Users who want to delete empty subvols should try - * rmdir(2). + * Users who want to delete empty subvols created by + * snapshot (ino number == 2) can use rmdir(2). */ - err = -EPERM; - if (!btrfs_test_opt(fs_info, USER_SUBVOL_RM_ALLOWED)) - goto out_dput; + err = -ENOTEMPTY; + if (inode->i_size != BTRFS_EMPTY_DIR_SIZE) { + if (!btrfs_test_opt(fs_info, USER_SUBVOL_RM_ALLOWED)) + goto out_dput; - /* - * Do not allow deletion if the parent dir is the same - * as the dir to be deleted. That means the ioctl - * must be called on the dentry referencing the root - * of the subvol, not a random directory contained - * within it. - */ - err = -EINVAL; - if (root == dest) - goto out_dput; + /* + * Do not allow deletion if the parent dir is the same + * as the dir to be deleted. That means the ioctl + * must be called on the dentry referencing the root + * of the subvol, not a random directory contained + * within it. + */ + err = -EINVAL; + if (root == dest) + goto out_dput; - err = inode_permission(inode, MAY_WRITE | MAY_EXEC); - if (err) - goto out_dput; + err = inode_permission(inode, MAY_WRITE | MAY_EXEC); + if (err) + goto out_dput; + } } /* check if subvolume may be deleted by a user */