Linux Security Modules development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH v6 5/8] selftests/landlock: Add namespace restriction tests
Date: Wed, 14 Oct 2026 08:41:38 +0000	[thread overview]
Message-ID: <sashiko-outbox-171031@kernel.org> (raw)
In-Reply-To: <20261014082718.1435842-6-mic@digikod.net>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] selftests: comment for user_unprivileged variant contradicts kernel behavior and test assertions
--

commit c04f6fe328bef28c5a3925e2b7cac5095784c173
Author: Mickaël Salaün <mic@digikod.net>

selftests/landlock: Add namespace restriction tests

This commit introduces comprehensive tests for the new namespace use
permission in Landlock. It covers namespace creation via unshare and clone,
as well as entry via setns, along with their interactions with capability
restrictions and audit logging.

> diff --git a/tools/testing/selftests/landlock/ns_test.c b/tools/testing/selftests/landlock/ns_test.c
> new file mode 100644
> index 0000000000000..f5d4b86edd303
> --- /dev/null
> +++ b/tools/testing/selftests/landlock/ns_test.c
[ ... ]
> +/*
> + * User namespace creation while unprivileged: the process has no capabilities
> + * but unshare(CLONE_NEWUSER) is an unprivileged operation so it still succeeds.
> + * The Landlock rule allows it.  For setns, the capability check (CAP_SYS_ADMIN)
> + * fails first since the process has no capabilities, yielding EPERM.
> + */

[Severity: Low]
Is the documentation for the setns behavior accurate here?

The comment states that the capability check fails first, yielding EPERM.
However, because the test targets the process's own user namespace
(/proc/self/ns/user), userns_install() checks if the target namespace
is the current user namespace and returns -EINVAL before any capability
checks are performed.

The test implementation correctly handles this by forcing the expected
result to EINVAL for user namespace re-entry:

TEST_F(ns_create, setns)
{
        ...
        if (variant->namespace_types == CLONE_NEWUSER &&
            !variant->expected_result) {
                expected = EINVAL;
        ...

Does the comment need to be updated to match the actual EINVAL expectation
rather than EPERM?

> +/* clang-format off */
> +FIXTURE_VARIANT_ADD(ns_create, user_unprivileged) {
> +	/* clang-format on */
> +	.namespace_types = CLONE_NEWUSER,
> +	.is_sandboxed = true,
> +	.has_rule = true,
> +	.drop_all_caps = true,
> +	.expected_result = 0,
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014082718.1435842-1-mic@digikod.net?part=5

  reply	other threads:[~2026-10-14  8:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  8:27 [PATCH v6 0/8] Landlock: Namespace and capability control Mickaël Salaün
2026-10-14  8:27 ` [PATCH v6 1/8] landlock: Rename quiet_masks to quiet_access Mickaël Salaün
2026-10-14  8:33   ` sashiko-bot
2026-10-14  8:27 ` [PATCH v6 2/8] landlock: Wrap per-layer access masks in struct layer_config Mickaël Salaün
2026-10-14  8:32   ` sashiko-bot
2026-10-14  8:27 ` [PATCH v6 3/8] landlock: Enforce namespace use restrictions Mickaël Salaün
2026-10-14  8:39   ` sashiko-bot
2026-10-14  8:27 ` [PATCH v6 4/8] landlock: Enforce capability restrictions Mickaël Salaün
2026-10-14  8:36   ` sashiko-bot
2026-10-14  8:27 ` [PATCH v6 5/8] selftests/landlock: Add namespace restriction tests Mickaël Salaün
2026-10-14  8:41   ` sashiko-bot [this message]
2026-10-14  8:27 ` [PATCH v6 6/8] selftests/landlock: Add capability " Mickaël Salaün
2026-10-14  8:43   ` sashiko-bot
2026-10-14  8:27 ` [PATCH v6 7/8] samples/landlock: Add capability and namespace restriction support Mickaël Salaün
2026-10-14  8:45   ` sashiko-bot
2026-10-14  8:27 ` [PATCH v6 8/8] landlock: Add documentation for capability and namespace restrictions Mickaël Salaün
2026-10-14  8:43   ` sashiko-bot

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=sashiko-outbox-171031@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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