From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
Jan Kara <jack@suse.cz>, Allison Karlitskaya <lis@redhat.com>
Subject: Re: [PATCH 1/2] mount: fix detached mount regression
Date: Fri, 6 Jun 2025 06:14:28 +0100 [thread overview]
Message-ID: <20250606051428.GT299672@ZenIV> (raw)
In-Reply-To: <20250606045441.GS299672@ZenIV>
On Fri, Jun 06, 2025 at 05:54:41AM +0100, Al Viro wrote:
> UGH...
>
> This is much too convoluted. How about this:
>
> /* The thing moved must be mounted... */
> if (!is_mounted(&old->mnt))
> goto out;
>
> /* ... and either ours or the root of anon namespace */
> if (check_mnt(old)) {
> /* should be detachable from parent */
> if (!mnt_has_parent(old) || IS_MNT_LOCKED(old))
> goto out;
> /* target should be ours */
> if (!check_mount(p))
check_mnt, obviously
> goto out;
> } else {
> if (!is_anon_ns(ns) || mnt_has_parent(old))
> goto out;
> /* not into the same anon ns - bail early in that case */
> if (p->mnt_ns == ns)
> goto out;
> /* target should be ours or in an acceptable anon */
> if (!may_use_mount(p))
> goto out;
> }
>
> Would that work for all cases?
The thing is, the real split is not on "has parent"; it's "is the
source in our namespace".
If it is, we must
* have 'attached' to be true (check_mnt() is incompatible with is_anon_ns())
IOW, mnt_has_parent(old) should be true.
* have no MNT_LOCKED on the source (we check it later, and it really belongs
here - we do *not* want to check it in move-from-anon case, since there we
accept only root and we never have MNT_LOCKED on the roots of anon namespaces
* have the target to be not in anon namespace. Which, combined with may_use_mount(p)
means that it should be in *our* namespace, so simply check_mnt(p). And that
subsumes may_use_mount(p), so no need to check it earlier.
* check for is_anon_ns(ns) && ns == p->mnt_ns obviously does not apply.
Otherwise, we know that 'attached' must be false and is_anon_ns(ns) - true.
Which means that we want the root of anon namespace.
* check for is_anon_ns(ns) && ns == p->mnt_ns turns into simply p->mnt_ns == ns
* check for target not being in anon namespace should be removed in this case -
that's the fix we are after.
* check for may_use_mount() is needed in this case.
* check for MNT_LOCKED is not needed afterwards - again, it's never set on the
root of anon
So everything prior to checking path_mounted() should be covered by the variant
above, and IMO it's easier to follow in that form - restrictions in 'move a
subtree of our namespace' and 'move the entire contents of anon namespace' are
rather different. Better keep them textually separate...
next prev parent reply other threads:[~2025-06-06 5:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 12:50 [PATCH 0/2] mount: fix detached mount regression Christian Brauner
2025-06-05 12:50 ` [PATCH 1/2] " Christian Brauner
2025-06-06 4:54 ` Al Viro
2025-06-06 5:14 ` Al Viro [this message]
2025-06-06 7:01 ` Al Viro
2025-06-06 7:58 ` Christian Brauner
2025-06-06 17:45 ` Al Viro
2025-06-07 5:20 ` Al Viro
2025-06-11 9:36 ` Christian Brauner
2025-06-11 17:29 ` Al Viro
2025-06-12 12:16 ` Christian Brauner
2025-06-05 12:50 ` [PATCH 2/2] selftests/mount_setattr: adapt detached mount propagation test 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=20250606051428.GT299672@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lis@redhat.com \
--cc=miklos@szeredi.hu \
/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).