From: Christian Brauner <firstname.lastname@example.org> To: Al Viro <email@example.com> Cc: Christian Brauner <firstname.lastname@example.org>, Tyler Hicks <email@example.com>, firstname.lastname@example.org, email@example.com, Amir Goldstein <firstname.lastname@example.org>, Miklos Szeredi <email@example.com> Subject: Re: [PATCH 2/3] ecryptfs: use private mount in path Date: Sat, 10 Apr 2021 14:30:37 +0200 Message-ID: <20210410123037.qlfjyv55ncdjpwn3@wittgenstein> (raw) In-Reply-To: <YHDxxunCKNuV34Oz@zeniv-ca.linux.org.uk> On Sat, Apr 10, 2021 at 12:31:02AM +0000, Al Viro wrote: > On Fri, Apr 09, 2021 at 06:24:21PM +0200, Christian Brauner wrote: > > > 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. > > > + mnt = clone_private_mount(&path); > > Incidentally, why is that thing anything other than a trivial wrapper > for mnt_clone_internal() (if that - I'm not convinced that the check of > unbindable is the right thing to do here). Miklos? The unbindable check is irrelevant at least for both ecryptfs and for the corresponding cachefiles change I sent out since they don't care about it. In practice it doesn't matter to be honest. MS_UNBINDABLE is wildly esoteric in userspace (We had a glaring bug with that some time ago that went completely unnoticed for years.). Especially unlikely to be used for a users home directory (ecryptfs) or /var/cache/fscache (cachefiles). So even by leaving this check in it's very unlikely for any regressions to appear. I hadn't seen mnt_clone_internal() but it's different in so far as it sets MNT_INTERNAL whereas clone_private_mount() uses MNT_NS_INTERNAL. Which points me to another potential problem here: clone_private_mount() seems to want kern_unmount() to be called instead of just a simple mntput()? If that's relevant then I think the unbindable check should probably move out of clone_private_mount() and into overlayfs itself but the rest be kept.
next prev parent reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-09 16:24 [PATCH 0/3] ecryptfs: fixes and port to private mounts Christian Brauner 2021-04-09 16:24 ` [PATCH 1/3] ecryptfs: remove unused helpers Christian Brauner 2021-04-19 4:48 ` Tyler Hicks 2021-04-19 13:49 ` Al Viro 2021-04-19 14:22 ` Tyler Hicks 2021-04-19 15:27 ` Al Viro 2021-04-19 14:37 ` Christian Brauner 2021-04-09 16:24 ` [PATCH 2/3] ecryptfs: use private mount in path Christian Brauner 2021-04-10 0:31 ` Al Viro 2021-04-10 12:30 ` Christian Brauner [this message] 2021-04-12 8:53 ` Miklos Szeredi 2021-04-09 16:24 ` [PATCH 3/3] ecryptfs: extend ro check to private mount 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=20210410123037.qlfjyv55ncdjpwn3@wittgenstein \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ firstname.lastname@example.org public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git