From: "Serge E. Hallyn" <serge@hallyn.com>
To: Ryan Foster <foster.ryan.r@gmail.com>
Cc: serge@hallyn.com, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, paul@paul-moore.com,
selinux@vger.kernel.org
Subject: Re: [PATCH v6] security: Add KUnit tests for kuid_root_in_ns and vfsuid_root_in_currentns
Date: Fri, 9 Jan 2026 22:50:05 -0600 [thread overview]
Message-ID: <aWHafb6DujTuEZ7l@mail.hallyn.com> (raw)
In-Reply-To: <20260107215725.105822-1-foster.ryan.r@gmail.com>
On Wed, Jan 07, 2026 at 01:51:28PM -0800, Ryan Foster wrote:
>
> Here's v6 with both fixes combined. The Dec 29 version you have in caps-next
> is correct for the namespace config - v6 keeps that and adds the KUNIT=y
> dependency to fix the Intel CI build error.
>
> Changes in v6:
> - Namespace config: all three namespaces are independent children of
> init_user_ns (same as Dec 29 you reviewed)
>
> - Build fix: depends on KUNIT=y prevents link errors when KUNIT=m
>
> The Dec 30 patch accidentally reverted the namespace fix when I was adding the
> KUNIT=y part. This v6 has both fixes working together.
>
> Thanks, Ryan
>
> Add comprehensive KUnit tests for the namespace-related capability
> functions that Serge Hallyn refactored in commit 9891d2f79a9f
> ("Clarify the rootid_owns_currentns").
>
> The tests verify:
> - Basic functionality: UID 0 in init namespace, invalid vfsuid,
> non-zero UIDs
> - Actual namespace traversal: Creating user namespaces with different
> UID mappings where uid 0 maps to different kuids (e.g., 1000, 2000,
> 3000)
> - Hierarchy traversal: Testing multiple nested namespaces to verify
> correct namespace hierarchy traversal
>
> This addresses the feedback to "test the actual functionality" by
> creating real user namespaces with different values for the
> namespace's uid 0, rather than just basic input validation.
>
> The test file is included at the end of commoncap.c when
> CONFIG_SECURITY_COMMONCAP_KUNIT_TEST is enabled, following the
> standard kernel pattern (e.g., scsi_lib.c, ext4/mballoc.c). This
> allows tests to access static functions in the same compilation unit
> without modifying production code based on test configuration.
>
> The tests require CONFIG_USER_NS to be enabled since they rely on user
> namespace mapping functionality. The Kconfig dependency ensures the
> tests only build when this requirement is met.
>
> All 7 tests pass:
> - test_vfsuid_root_in_currentns_init_ns
> - test_vfsuid_root_in_currentns_invalid
> - test_vfsuid_root_in_currentns_nonzero
> - test_kuid_root_in_ns_init_ns_uid0
> - test_kuid_root_in_ns_init_ns_nonzero
> - test_kuid_root_in_ns_with_mapping
> - test_kuid_root_in_ns_with_different_mappings
>
> Updated MAINTAINER capabilities to include commoncap test
>
> Signed-off-by: Ryan Foster <foster.ryan.r@gmail.com>
Thanks, applied to git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git #caps-next
prev parent reply other threads:[~2026-01-10 4:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 14:37 [PATCH] security: Add KUnit tests for rootid_owns_currentns() Ryan Foster
2025-11-11 0:33 ` Serge E. Hallyn
2025-11-11 6:52 ` kernel test robot
2025-11-11 7:03 ` kernel test robot
2025-11-21 17:48 ` [PATCH v2] security: Rename functions and add namespace mapping tests Ryan Foster
2025-11-25 15:15 ` Serge E. Hallyn
2025-12-04 21:56 ` [PATCH] security: Add KUnit tests for kuid_root_in_ns and vfsuid_root_in_currentns Ryan Foster
2025-12-16 22:57 ` Paul Moore
2025-12-18 18:49 ` [PATCH v3 sec cap tests] " Ryan Foster
2025-12-28 19:45 ` commoncap KUnit tests v4 Ryan Foster
2025-12-28 19:45 ` [PATCH v4] security: Add KUnit tests for kuid_root_in_ns and vfsuid_root_in_currentns Ryan Foster
2025-12-29 4:14 ` Serge E. Hallyn
2025-12-29 14:23 ` [PATCH v5] " Ryan Foster
2025-12-29 13:56 ` [PATCH v4] " kernel test robot
2025-12-29 18:35 ` kernel test robot
2025-12-30 15:13 ` [PATCH v5] " Ryan Foster
2026-01-06 21:07 ` Serge E. Hallyn
2026-01-07 21:51 ` [PATCH v6] " Ryan Foster
2026-01-10 4:50 ` Serge E. Hallyn [this message]
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=aWHafb6DujTuEZ7l@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=foster.ryan.r@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
/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.