From patchwork Fri Apr 9 16:24:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 12194445 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E42EAC433ED for ; Fri, 9 Apr 2021 16:25:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 992486108B for ; Fri, 9 Apr 2021 16:25:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233892AbhDIQ0L (ORCPT ); Fri, 9 Apr 2021 12:26:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:34138 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231946AbhDIQ0K (ORCPT ); Fri, 9 Apr 2021 12:26:10 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 346E56105A; Fri, 9 Apr 2021 16:25:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617985557; bh=WTQH0udz0NF8TztvnwMq88N10RCV7bqnuzOPfNws+Iw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fTlp1TSs29mHNs41k3ZC0N505SOsY11qPa3OJRwtW3BI67YF3RcCgkpqKFNgnTXwS YLLxH23aS5Pi8tMTTCDPtHjWMJY+VXskiTtooFqoSf+Gym/9mo3dW8G47Jca5yZ2uK mB4JNKp+prYvoZBPpGo13ETqZXfql9TIc7rX5P3AtwEXwASvWtEnurAnGDhDGdoOmd dJ6yQZh8nF6azGVITA40z+fDKFT4hGxnSeBbC89dOD36G8c8mX4502UGwLhHDSr2q1 AyrEcjObvwndY0NcYMWH5dMu5SAnkIKaOcrhDQd+0hDwa4kWjJ6rOdo/68az+Iu5U7 ajq7VMMpnC24g== From: Christian Brauner To: Tyler Hicks , ecryptfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, Amir Goldstein , Christian Brauner Subject: [PATCH 1/3] ecryptfs: remove unused helpers Date: Fri, 9 Apr 2021 18:24:20 +0200 Message-Id: <20210409162422.1326565-2-brauner@kernel.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210409162422.1326565-1-brauner@kernel.org> References: <20210409162422.1326565-1-brauner@kernel.org> MIME-Version: 1.0 X-Patch-Hashes: v=1; h=sha256; i=nzTvFnw3t4txDemcI17R/llUoqTSs+bJqW4FdAPoLKw=; m=J+qTInv0+c941FPP/DKnPR+q4fv+TijG5Mmocs7tYFA=; p=BwaSmLmuxC+Mnisblg4+PrmO+E3cXIi4r/5K2IN1AlY=; g=dbcf757b805a2d3101414e705db92ef74807805c X-Patch-Sig: m=pgp; i=christian.brauner@ubuntu.com; s=0x0x91C61BC06578DCA2; b=iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCYHB/qwAKCRCRxhvAZXjcoujCAQCL4Ot rt00cS9vtS4rQ/+DSZv/mAcTlquH6sSA1pV2ngAD8CFNsFjRJhZo7Uhs81C6mnv0OQryrd2RbDbKg +LElmAw= Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org From: Christian Brauner Remove two helpers that are unused. Cc: Amir Goldstein Cc: Tyler Hicks Cc: ecryptfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner --- fs/ecryptfs/ecryptfs_kernel.h | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h index e6ac78c62ca4..463b2d99b554 100644 --- a/fs/ecryptfs/ecryptfs_kernel.h +++ b/fs/ecryptfs/ecryptfs_kernel.h @@ -496,12 +496,6 @@ ecryptfs_set_superblock_lower(struct super_block *sb, ((struct ecryptfs_sb_info *)sb->s_fs_info)->wsi_sb = lower_sb; } -static inline struct ecryptfs_dentry_info * -ecryptfs_dentry_to_private(struct dentry *dentry) -{ - return (struct ecryptfs_dentry_info *)dentry->d_fsdata; -} - static inline void ecryptfs_set_dentry_private(struct dentry *dentry, struct ecryptfs_dentry_info *dentry_info) @@ -515,12 +509,6 @@ ecryptfs_dentry_to_lower(struct dentry *dentry) return ((struct ecryptfs_dentry_info *)dentry->d_fsdata)->lower_path.dentry; } -static inline struct vfsmount * -ecryptfs_dentry_to_lower_mnt(struct dentry *dentry) -{ - return ((struct ecryptfs_dentry_info *)dentry->d_fsdata)->lower_path.mnt; -} - static inline struct path * ecryptfs_dentry_to_lower_path(struct dentry *dentry) { From patchwork Fri Apr 9 16:24:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 12194447 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C7D7C433B4 for ; Fri, 9 Apr 2021 16:26:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2C5F06108B for ; Fri, 9 Apr 2021 16:26:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233957AbhDIQ0P (ORCPT ); Fri, 9 Apr 2021 12:26:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:34186 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231946AbhDIQ0O (ORCPT ); Fri, 9 Apr 2021 12:26:14 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 523516105A; Fri, 9 Apr 2021 16:25:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617985561; bh=J8t17g23+btk3F9jOLqdBzPhP1M+ElUmU2FMOvdU35s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uYeb/mFm+mEB0QdiF1/xJqPdxDngRuMpjybOG2/06Q7K+yLL0Vor6hwciE5X+lYRk LX+o7BxirbIPeGapNhfyLS/golrvzFZCwmM1N9K/se5LcQvLrqozE3jDFHwmTEIL2r xS/hs2V46dkAmdW9PuosHGxBHjlDoGCZnByL4SYck+C7Egfd59B5thaMRb1X16xzVl +PrgehGxXRaCgeiUHeCS62CQfgr9xPQ9ynxdQuSrvv6kWA8jDZAq7AjE93kGqU1toW 3FEYmoBPom3zPp5SYThpqT158q6K30o6UVGtejhK7jtH7BqlA54/O9alxY49xe8dcZ IawG+eMlpIyxw== From: Christian Brauner To: Tyler Hicks , ecryptfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, Amir Goldstein , Christian Brauner Subject: [PATCH 2/3] ecryptfs: use private mount in path Date: Fri, 9 Apr 2021 18:24:21 +0200 Message-Id: <20210409162422.1326565-3-brauner@kernel.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210409162422.1326565-1-brauner@kernel.org> References: <20210409162422.1326565-1-brauner@kernel.org> MIME-Version: 1.0 X-Patch-Hashes: v=1; h=sha256; i=cTiuNNElCYkKGQaeMRo+ULrYG/J4jrYXaS1E1zaTBsk=; m=BfKPJZd/WyI8d3+yV455yfmFFC3JWxIMysPbkeJUUeI=; p=SB/NGq7zX1GFwVbjpRQ5dn1d2ILPE3+QigJ5r9vh9zc=; g=ec6964566ef553203b82917ad7a9c494550e550c X-Patch-Sig: m=pgp; i=christian.brauner@ubuntu.com; s=0x0x91C61BC06578DCA2; b=iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCYHB/qwAKCRCRxhvAZXjcotgvAPwIhxR vKIQtVgJUZt45ahP/CuM18PjakMhf7IsURPf1eAD/e09EvDHpouyxDuJAdBr4/V103r6dG2cMCltR GCXC7gs= Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org From: Christian Brauner Since [1] we support creating private mounts from a given path's vfsmount. This makes them very suitable for any filesystem or filesystem functionality that piggybacks on paths of another filesystem. Overlayfs, cachefiles, and ecryptfs are three prime examples. Since private mounts aren't attached in the filesystem they aren't affected by mount property changes after ecryptfs makes use of them. This seems a rather desirable property as the underlying path can't e.g. suddenly go from read-write to read-only and in general it means that ecryptfs is always in full control of the underlying mount after the user has allowed it to be used (apart from operations that affect the superblock of course). Besides that it also makes things simpler for a variety of other vfs features. One concrete example is fanotify. When the path->mnt of the path that is used as a cache has been marked with FAN_MARK_MOUNT the semantics get tricky as it isn't clear whether the watchers of path->mnt should get notified about fsnotify events when files are created by cachefilesd via path->mnt. Using a private mount let's us elegantly handle this case too and aligns the behavior of stacks created by overlayfs and cachefiles. Reading through the codebase of ecryptfs it currently takes path->mnt and then retrieves that path whenever it needs to perform operations in the underlying filesystem. Simply drop the old path->mnt once we've created a private mount and place the new private mnt into path->mnt. This should be all that is needed to make this work since ecryptfs uses the same lower path's vfsmount to construct the paths it uses to operate on the underlying filesystem. [1]: c771d683a62e ("vfs: introduce clone_private_mount()") Cc: Amir Goldstein Cc: Tyler Hicks Cc: ecryptfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner --- fs/ecryptfs/main.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c index cdf40a54a35d..9dcf9a0dd37b 100644 --- a/fs/ecryptfs/main.c +++ b/fs/ecryptfs/main.c @@ -476,6 +476,7 @@ static struct file_system_type ecryptfs_fs_type; static struct dentry *ecryptfs_mount(struct file_system_type *fs_type, int flags, const char *dev_name, void *raw_data) { + struct vfsmount *mnt = NULL; struct super_block *s; struct ecryptfs_sb_info *sbi; struct ecryptfs_mount_crypt_stat *mount_crypt_stat; @@ -537,6 +538,14 @@ static struct dentry *ecryptfs_mount(struct file_system_type *fs_type, int flags goto out_free; } + mnt = clone_private_mount(&path); + if (IS_ERR(mnt)) { + rc = PTR_ERR(mnt); + mnt = NULL; + pr_warn("Failed to create private mount for ecryptfs\n"); + goto out_free; + } + if (check_ruid && !uid_eq(d_inode(path.dentry)->i_uid, current_uid())) { rc = -EPERM; printk(KERN_ERR "Mount of device (uid: %d) not owned by " @@ -592,6 +601,13 @@ static struct dentry *ecryptfs_mount(struct file_system_type *fs_type, int flags /* ->kill_sb() will take care of root_info */ ecryptfs_set_dentry_private(s->s_root, root_info); + + /* We've created a private clone of this mount above so drop it now. */ + mntput(path.mnt); + + /* Use our private mount from now on. */ + path.mnt = mnt; + root_info->lower_path = path; s->s_flags |= SB_ACTIVE; @@ -599,6 +615,7 @@ static struct dentry *ecryptfs_mount(struct file_system_type *fs_type, int flags out_free: path_put(&path); + mntput(mnt); out1: deactivate_locked_super(s); out: From patchwork Fri Apr 9 16:24:22 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 12194449 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFA9EC433ED for ; Fri, 9 Apr 2021 16:26:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AC959610A8 for ; Fri, 9 Apr 2021 16:26:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233995AbhDIQ0T (ORCPT ); Fri, 9 Apr 2021 12:26:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:34238 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233674AbhDIQ0S (ORCPT ); Fri, 9 Apr 2021 12:26:18 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 34B576103E; Fri, 9 Apr 2021 16:26:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617985565; bh=/Hl5eHU8L4xr6JaOlwwlyG6clIdkW90gmNVCkqKbsJI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pnBOIp04pVcL4je5JxqNo+Q5HD23QWJ0wqjtE9noWMDU3YFNk4yfI87IYaFinoiuO ybiFqXHjtT6VM350vRtJmE7/HXin3vFCa+Tf7d+ZDWzHDOcBJaxc12nj8qQ1KUTgOI Z2RAPV3e4feiaJ81tPsus8CNtAULeP3Ytz5a1ROfTR4OyDnBiMz0ghL9ZG/FzcbBYA W4ihsHmPH1Vu0m1BA/sdfqEVLZlLlGfkl/9PMIIvd5uSKg3jUmlZNVyqhMMFNbI8/9 RyKnlSMT6KW1NZ7y/kVYc816UT+iT4EK9HaeKpg5N91S6sO4Zww3DcjUnuekN7yxyP /H4FYI+ZeJ7Qw== From: Christian Brauner To: Tyler Hicks , ecryptfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, Amir Goldstein , Christian Brauner Subject: [PATCH 3/3] ecryptfs: extend ro check to private mount Date: Fri, 9 Apr 2021 18:24:22 +0200 Message-Id: <20210409162422.1326565-4-brauner@kernel.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210409162422.1326565-1-brauner@kernel.org> References: <20210409162422.1326565-1-brauner@kernel.org> MIME-Version: 1.0 X-Patch-Hashes: v=1; h=sha256; i=TJq3ADscBRuq3vVMRrZQ25nFLYThkfCmWR4OfInmRrw=; m=1ciTf4lEciTeOTFMYE8Ti/zNFh88dj9ns8fWVydD8Es=; p=lH6ypLy7nBSAU1Y8+OlROQnduiSVhzKO3zb3sUcPmzw=; g=0d107768135058226d796803890d0dee0a0e7ec6 X-Patch-Sig: m=pgp; i=christian.brauner@ubuntu.com; s=0x0x91C61BC06578DCA2; b=iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCYHB/qwAKCRCRxhvAZXjcoqPRAQDNdrN i3wEqHRmR7SJY4F0Q5iNfmpejbX7iJwoaooOKIQD+ONXL9uXlqTTTfpuw2HNXE7y9BIaV0nX4TY+o Bx2U+ww= Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org From: Christian Brauner So far ecryptfs only verified that the superblock wasn't read-only but didn't check whether the mount was. This made sense when we did not use a private mount because the read-only state could change at any point. Now that we have a private mount and mount properties can't change behind our back extend the read-only check to include the vfsmount. The __mnt_is_readonly() helper will check both the mount and the superblock. Note that before we checked root->d_sb and now we check mnt->mnt_sb but since we have a matching pair here this is only syntactical change, not a semantic one. Overlayfs and cachefiles have been changed to check this as well. Cc: Amir Goldstein Cc: Tyler Hicks Cc: ecryptfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner --- fs/ecryptfs/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c index 9dcf9a0dd37b..cdf37d856c62 100644 --- a/fs/ecryptfs/main.c +++ b/fs/ecryptfs/main.c @@ -569,7 +569,7 @@ static struct dentry *ecryptfs_mount(struct file_system_type *fs_type, int flags * 1) The lower mount is ro * 2) The ecryptfs_encrypted_view mount option is specified */ - if (sb_rdonly(path.dentry->d_sb) || mount_crypt_stat->flags & ECRYPTFS_ENCRYPTED_VIEW_ENABLED) + if (__mnt_is_readonly(mnt) || mount_crypt_stat->flags & ECRYPTFS_ENCRYPTED_VIEW_ENABLED) s->s_flags |= SB_RDONLY; s->s_maxbytes = path.dentry->d_sb->s_maxbytes;