From: "Mickaël Salaün" <mic@digikod.net>
To: sashiko-reviews@lists.linux.dev
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH v4 7/8] samples/landlock: Add capability and namespace restriction support
Date: Tue, 6 Oct 2026 11:57:46 +0200 [thread overview]
Message-ID: <20261006.FaeKaeteefe4@digikod.net> (raw)
In-Reply-To: <20261002125330.A4FA11F000FF@smtp.kernel.org>
On Fri, Oct 02, 2026 at 12:53:30PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Low] build: sample landlock fails on systems without libcap-dev
> - [Low] build: missing fallback for CLONE_NEWTIME breaks build on glibc < 2.33
> --
>
> commit c88aebdbd55f6c34b61885d4e3d918bc61983af0
> Author: Mickaël Salaün <mic@digikod.net>
>
> samples/landlock: Add capability and namespace restriction support
>
> This commit extends the sandboxer sample to demonstrate new Landlock
> capability and namespace restriction features. It allows parsing allowed
> namespaces and capabilities using libcap, adding appropriate command line
> arguments for testing.
>
> > diff --git a/samples/Kconfig b/samples/Kconfig
> > index a75e8e78330da..b18efc19b85d0 100644
> > --- a/samples/Kconfig
> > +++ b/samples/Kconfig
> > @@ -166,8 +166,10 @@ config SAMPLE_LANDLOCK
> > bool "Landlock example"
> > depends on CC_CAN_LINK && HEADERS_INSTALL
> > help
> > - Build a simple Landlock sandbox manager able to start a process
> > - restricted by a user-defined filesystem access control policy.
> > + Build a Landlock sandbox manager able to start a process restricted
> > + by user-defined filesystem, network, scope, namespace, and capability
> > + policies. This sample requires the libcap development headers and
> > + library.
> >
> > config SAMPLE_PIDFD
> > bool "pidfd sample"
>
> [ ... ]
>
> > diff --git a/samples/landlock/Makefile b/samples/landlock/Makefile
> > index 5d601e51c2ebf..b30239c8a281c 100644
> > --- a/samples/landlock/Makefile
> > +++ b/samples/landlock/Makefile
> > @@ -3,6 +3,7 @@
> > userprogs-always-y := sandboxer
> >
> > userccflags += -I usr/include
> > +userldlibs += -lcap
>
> [Severity: Low]
> Does this unconditional linking cause build failures during make allmodconfig
> or make samples if the host system lacks the libcap-dev library?
>
> Since the Kconfig does not verify the presence of the libcap library (for
> example, using a $(success,...) check), the build will unconditionally
> attempt to link against it and fail when the dependency is missing. Could a
> dependency check be added in the Kconfig to prevent breaking automated
> testing on minimal host environments?
I'll make libcap-dev optional.
>
> >
> > .PHONY: all clean
>
> [ ... ]
>
> > diff --git a/samples/landlock/sandboxer.c b/samples/landlock/sandboxer.c
> > index 030583273f3f7..4a86ae6d4552d 100644
> > --- a/samples/landlock/sandboxer.c
> > +++ b/samples/landlock/sandboxer.c
> > @@ -232,6 +241,166 @@ static int populate_ruleset_net(const char *const env_var, const int ruleset_fd,
> > return ret;
> > }
> >
> > +static __u64 str2ns(const char *const name)
> > +{
> > + static const struct {
> > + const char *name;
> > + __u64 value;
> > + } ns_map[] = {
> > + /* clang-format off */
> > + { "cgroup", CLONE_NEWCGROUP },
> > + { "ipc", CLONE_NEWIPC },
> > + { "mnt", CLONE_NEWNS },
> > + { "net", CLONE_NEWNET },
> > + { "pid", CLONE_NEWPID },
> > + { "time", CLONE_NEWTIME },
>
> [Severity: Low]
> Will this missing fallback macro for CLONE_NEWTIME cause compilation failures
> on older host environments?
>
> The CLONE_NEWTIME macro was added to the glibc sched.h header starting in
> version 2.33. If the sample is built on a system with an older glibc, it
> fails to compile. Can we add a fallback preprocessor definition for
> CLONE_NEWTIME so the sample can still build on older distributions?
I'll use the kernel headers.
>
> > + { "user", CLONE_NEWUSER },
> > + { "uts", CLONE_NEWUTS },
> > + /* clang-format on */
> > + };
> > + size_t i;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261002124409.1277970-1-mic@digikod.net?part=7
>
next prev parent reply other threads:[~2026-10-06 9:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 12:43 [PATCH v4 0/8] Landlock: Namespace and capability control Mickaël Salaün
2026-10-02 12:43 ` [PATCH v4 1/8] landlock: Rename quiet_masks to quiet_access Mickaël Salaün
2026-10-02 12:50 ` sashiko-bot
2026-10-02 12:43 ` [PATCH v4 2/8] landlock: Wrap per-layer access masks in struct layer_config Mickaël Salaün
2026-10-02 12:49 ` sashiko-bot
2026-10-02 12:43 ` [PATCH v4 3/8] landlock: Enforce namespace use restrictions Mickaël Salaün
2026-10-02 12:52 ` sashiko-bot
2026-10-02 12:43 ` [PATCH v4 4/8] landlock: Enforce capability restrictions Mickaël Salaün
2026-10-02 12:53 ` sashiko-bot
2026-10-02 12:43 ` [PATCH v4 5/8] selftests/landlock: Add namespace restriction tests Mickaël Salaün
2026-10-02 12:56 ` sashiko-bot
2026-10-06 9:56 ` Mickaël Salaün
2026-10-02 12:43 ` [PATCH v4 6/8] selftests/landlock: Add capability " Mickaël Salaün
2026-10-02 12:53 ` sashiko-bot
2026-10-06 9:57 ` Mickaël Salaün
2026-10-02 12:44 ` [PATCH v4 7/8] samples/landlock: Add capability and namespace restriction support Mickaël Salaün
2026-10-02 12:53 ` sashiko-bot
2026-10-06 9:57 ` Mickaël Salaün [this message]
2026-10-02 12:44 ` [PATCH v4 8/8] landlock: Add documentation for capability and namespace restrictions Mickaël Salaün
2026-10-02 12:59 ` 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=20261006.FaeKaeteefe4@digikod.net \
--to=mic@digikod.net \
--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