Linux Security Modules development
 help / color / mirror / Atom feed
From: Peng Hao <flyingpenghao@gmail.com>
To: mic@digikod.net, gnoack@google.com
Cc: linux-security-module@vger.kernel.org
Subject: [PATCH] selftests/landlock: prevent mount propagation from test namespaces
Date: Fri, 28 Aug 2026 20:13:34 +0800	[thread overview]
Message-ID: <20260828121334.26804-1-flyingpeng@tencent.com> (raw)

The filesystem fixtures create TMP_DIR, unshare the mount namespace, and
then mount a temporary filesystem.  A new mount namespace inherits the
parent's propagation state, so on systems with a shared mount tree the
new mount can propagate back into the parent namespace before TMP_DIR is
made private.

The parent teardown can then find TMP_DIR still mounted and return EBUSY.
Its ASSERT_EQ() stops cleanup before remove_path(), leaving stale state
that makes later tests fail with EEXIST.

Make the complete mount tree recursively private immediately after
unshare(), before creating the fixture mount.  If propagation setup
fails, remove TMP_DIR because fixture teardown will not run.

Also make teardown continue after an unexpected unmount result.  Report
anything other than the expected EINVAL as a test failure, but lazily
detach an EBUSY mount and always attempt to remove TMP_DIR so one failure
does not cascade into later tests.

Fixes: e1199815b47b ("selftests/landlock: Add user space tests")
Signed-off-by: Peng Hao <flyingpeng@tencent.com>
---
 tools/testing/selftests/landlock/fs_test.c | 28 ++++++++++++++++++----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index 86e08aa6e0a7..72c2a8bef146 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -305,6 +305,16 @@ static void prepare_layout_opt(struct __test_metadata *const _metadata,
 	 */
 	set_cap(_metadata, CAP_SYS_ADMIN);
 	ASSERT_EQ(0, unshare(CLONE_NEWNS | CLONE_NEWCGROUP));
+	/*
+	 * A new mount namespace inherits its parent's propagation state.  Make
+	 * the whole tree private before creating mounts below TMP_DIR so none
+	 * of them can propagate back to the parent namespace.
+	 */
+	ASSERT_EQ(0, mount(NULL, "/", NULL, MS_PRIVATE | MS_REC, NULL))
+	{
+		clear_cap(_metadata, CAP_SYS_ADMIN);
+		remove_path(TMP_DIR);
+	}
 	ASSERT_EQ(0, mount_opt(mnt, TMP_DIR))
 	{
 		TH_LOG("Failed to mount the %s filesystem: %s", mnt->type,
@@ -330,13 +340,21 @@ static void cleanup_layout(struct __test_metadata *const _metadata)
 {
 	set_cap(_metadata, CAP_SYS_ADMIN);
 	if (umount(TMP_DIR)) {
+		int err = errno;
+
 		/*
-		 * According to the test environment, the mount point of the
-		 * current directory may be shared or not, which changes the
-		 * visibility of the nested TMP_DIR mount point for the test's
-		 * parent process doing this cleanup.
+		 * The child normally owns the TMP_DIR mount in its private mount
+		 * namespace, so the parent teardown should only see EINVAL.  If a
+		 * mount is unexpectedly still visible, report the failure but
+		 * detach it so one broken test cannot cascade into later tests.
 		 */
-		ASSERT_EQ(EINVAL, errno);
+		EXPECT_EQ(EINVAL, err)
+		{
+			TH_LOG("Unexpected umount errno=%d (%s)", err,
+			       strerror(err));
+		}
+		if (err == EBUSY)
+			EXPECT_EQ(0, umount2(TMP_DIR, MNT_DETACH));
 	}
 	clear_cap(_metadata, CAP_SYS_ADMIN);
 	EXPECT_EQ(0, remove_path(TMP_DIR));
-- 
2.43.7


                 reply	other threads:[~2026-08-28 12:13 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260828121334.26804-1-flyingpeng@tencent.com \
    --to=flyingpenghao@gmail.com \
    --cc=gnoack@google.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    /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