jdx/mise · error

failed to apply landlock restrictions: {status:?}

Error message

failed to apply landlock restrictions: {status:?}

What it means

After building Landlock rules for sandbox read/write restrictions and calling restrict_self, mise verifies enforcement: status.ruleset must not be RulesetStatus::NotEnforced and the no_new_privs flag must be set. If the kernel silently did not enforce the ruleset (kernel without Landlock, Landlock LSM disabled at boot) or prctl(PR_SET_NO_NEW_PRIVS) failed, mise aborts rather than continue under a false sense of sandboxing. Note restrict_self's own error produces a different message; this one covers 'succeeded but not enforced'.

Source

Thrown at src/sandbox/landlock.rs:153

        // allow_write paths are implicitly readable
        for path in &config.allow_write {
            ruleset = add_path_rule(ruleset, path, read_access)?;
        }
    } else if deny_write {
        // Only writes restricted — allow read everywhere, deny write except allowed paths
        ruleset = add_read_rule(ruleset, "/", read_access)?;
        ruleset = add_read_rule(ruleset, "/tmp", full_access)?;
        ruleset = add_read_rule(ruleset, "/dev", full_access)?;
        for path in &config.allow_write {
            ruleset = add_path_rule(ruleset, path, full_access)?;
        }
    }

    let status = ruleset
        .restrict_self()
        .map_err(|e| eyre!("failed to apply landlock restrictions: {e}"))?;
    if status.ruleset == RulesetStatus::NotEnforced || !status.no_new_privs {
        eyre::bail!("failed to apply landlock restrictions: {status:?}");
    }

    Ok(())
}

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

1. If in a container, run on a runtime/seccomp profile that allows the landlock_* syscalls (recent Docker/containerd defaults do), or supply a permissive profile for the job.
2. Enable the Landlock LSM: boot with lsm=...,landlock (and ensure the kernel is built with CONFIG_SECURITY_LANDLOCK).
3. Upgrade to a kernel >= 5.13 (>= 5.19 for full path-beneath features).
4. If sandboxing is not required for this run, drop the --deny-read/--deny-write flags (or task sandbox config) so landlock is not applied.

Example fix

# before: fails in a container blocking landlock syscalls
mise x --sandbox --deny-write -- npm run build
# after: allow the syscalls or drop the sandbox for this step
docker run --security-opt seccomp=landlock-profile.json ... mise x --sandbox --deny-write -- npm run build
# or
mise x -- npm run build

#!/usr/bin/env bash
# fail fast before running sandboxed commands on hosts without working landlock
set -e
kver=$(uname -r | cut -d. -f1-2)
awk -v v="$kver" 'BEGIN{split(v,a,"."); exit !(a[1]>5 || (a[1]==5 && a[2]>=13))}' || { echo 'kernel lacks landlock' >&2; exit 1; }
grep -q landlock /sys/kernel/security/lsm 2>/dev/null || grep -q landlock /proc/cmdline || { echo 'landlock LSM not enabled' >&2; exit 1; }
mise x --sandbox --deny-write -- "$@"

Run the sandboxed command; on failure containing 'failed to apply landlock restrictions', fall back to running the same command without --deny-read/--deny-write and flag the job as unsandboxed (do not silently retry sandboxed).

When it happens

Trigger: Running a mise command or task with sandbox restrictions (--deny-read/--deny-write or task sandbox settings) on a kernel older than 5.13, a kernel booted without the landlock LSM in the lsm= list, or inside a container whose seccomp policy blocks the landlock_create_ruleset/landlock_add_rule/landlock_restrict_self syscalls so the ruleset lands in NotEnforced state.

Common situations: CI containers (Docker's default seccomp profile on older engines blocks landlock syscalls), older Debian/Ubuntu LTS kernels, WSL2 kernels without Landlock, minimal VM images compiled without CONFIG_SECURITY_LANDLOCK, hosts that boot with a restrictive lsm= kernel parameter.

Related errors

• per-host network filtering (--allow-net=<host>) is not suppo
• per-host network filtering (--allow-net=<host>) is not suppo
• {operation} is disabled in safe mode (MISE_SAFE=1) See https
• content-level SLSA verification rejected unsafe archive path
• bootstrap users and groups are only supported on Linux

AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/a8610f41a9a8dce5. Report an issue: GitHub.