What causes "failed to apply landlock restrictions: {status:?}" in jdx/mise?

Run on a kernel >= 5.13 with the Landlock LSM enabled (`lsm=landlock,...` in kernel cmdline).

failed to apply landlock restrictions

Error message

failed to apply landlock restrictions: {status:?}

What it means

`apply_landlock` applies a Linux Landlock sandbox via `ruleset.restrict_self()`. After the call, it verifies that Landlock is actually enforced (`RulesetStatus::NotEnforced` means the kernel ignored the rules) and that `no_new_privs` is set; otherwise it bails, because silently running unsandboxed would be unsafe.

Solutions

Run on a kernel >= 5.13 with the Landlock LSM enabled (`lsm=landlock,...` in kernel cmdline).
Remove `--deny-read`/`--deny-write`/`--deny-process` flags if the environment cannot support Landlock.
Run the command outside the restrictive container/VM, or ask the platform to permit landlock_create_ruleset/restrict_self and PR_SET_NO_NEW_PRIVS.

Example fix

// before (fails in old container)
mise x --deny-write ./target:mise-sandbox -- make test
// after
mise x -- make test  # without landlock-requiring flags, or upgrade host kernel

Defensive patterns

Strategy: fallback

Validate before calling

uname -r  # require >= 5.13; check /sys/kernel/security/lsm for landlock

Try / catch

try {
  await $`mise x --deny-write -- <cmd>`;
} catch (e) {
  if (String(e).includes('failed to apply landlock'))
    console.error('Kernel/LSM lacks Landlock; rerun without sandbox flags');
  throw e;
}

Prevention

Verify kernel >= 5.13 and landlock in the LSM list before using --deny-read/--deny-write.
Avoid sandbox flags inside containers known to strip Landlock/no_new_privs.

When it happens

Trigger: Running a sandboxed command on a Linux kernel without Landlock support (< 5.13) or with the LSM disabled; running in a container that filters the landlock syscalls; a seccomp/LSA profile blocking `prctl(PR_SET_NO_NEW_PRIVS)`.

Common situations: Docker containers with older base kernels or restricted LSMs; WSL1; hardened environments where no_new_privs is stripped; `mise x --sandbox` style commands inside CI images lacking Landlock.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

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

Appendix: source

Thrown at src/sandbox/landlock.rs:200

        for path in &config.allow_write {
            ruleset = add_path_rule(ruleset, path, full_access)?;
        }
    }

    // The ruleset is installed before the target's initial exec. Permit that
    // exact executable while denying later execve/execveat calls for every
    // other file (including Kernel.exec from evaluated tap Ruby).
    if config.deny_process
        && let Some(program) = initial_program
    {
        ruleset = add_path_rule(ruleset, program, execute_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 533346cc37)