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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.