zeroclaw-labs/zeroclaw · error · std::io::Error

Landlock is only supported on Linux with the sandbox-landloc

Error message

Landlock is only supported on Linux with the sandbox-landlock feature

What it means

This error comes from the compile-time stub of LandlockSandbox, which exists whenever the crate is built without the `sandbox-landlock` cargo feature or for a non-Linux target (the `#[cfg(not(all(feature = "sandbox-landlock", target_os = "linux")))]` block at landlock.rs:307). The stub keeps the type nameable on every platform so downstream code compiles, but every constructor returns io::ErrorKind::Unsupported. Hitting it means the binary was never built with Landlock support at all — not that the host kernel lacks Landlock (that case produces the real implementation's distinct "Landlock not available" error).

Source

Thrown at crates/zeroclaw-runtime/src/security/landlock.rs:314

    fn name(&self) -> &str {
        "landlock"
    }

    fn description(&self) -> &str {
        "Linux kernel LSM sandboxing (filesystem access control)"
    }
}

// Stub implementations for non-Linux or when feature is disabled
#[cfg(not(all(feature = "sandbox-landlock", target_os = "linux")))]
#[derive(Debug)]
pub struct LandlockSandbox;

#[cfg(not(all(feature = "sandbox-landlock", target_os = "linux")))]
impl LandlockSandbox {
    pub fn new() -> std::io::Result<Self> {
        Err(std::io::Error::new(
            std::io::ErrorKind::Unsupported,
            "Landlock is only supported on Linux with the sandbox-landlock feature",
        ))
    }

    pub fn with_workspace(_workspace_dir: Option<std::path::PathBuf>) -> std::io::Result<Self> {
        Err(std::io::Error::new(
            std::io::ErrorKind::Unsupported,
            "Landlock is only supported on Linux",
        ))
    }

    pub fn probe() -> std::io::Result<Self> {
        Err(std::io::Error::new(
            std::io::ErrorKind::Unsupported,
            "Landlock is only supported on Linux",
        ))
    }

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Rebuild on Linux with the feature enabled: `cargo build --features zeroclaw-runtime/sandbox-landlock` (or add `sandbox-landlock` to the features list in your Cargo.toml dependency on zeroclaw-runtime)
  2. On macOS, use the Seatbelt backend (SeatbeltSandbox) instead — Landlock is Linux-only by design
  3. Gate the call site with `#[cfg(all(feature = "sandbox-landlock", target_os = "linux"))]` and provide an alternate branch for other platforms
  4. In backend auto-detection, treat ErrorKind::Unsupported from new()/probe() as "backend not compiled in" and continue to the next candidate instead of propagating the error

Example fix

// before
let sandbox = LandlockSandbox::new()?; // Err(Unsupported) on non-Linux or feature-off builds

// after — only construct Landlock when it was actually compiled in
fn pick_sandbox() -> std::io::Result<Box<dyn zeroclaw_runtime::security::traits::Sandbox>> {
    #[cfg(all(feature = "sandbox-landlock", target_os = "linux"))]
    { return Ok(Box::new(LandlockSandbox::new()?)); }
    #[cfg(not(all(feature = "sandbox-landlock", target_os = "linux")))]
    { return Ok(Box::new(fallback_backend()?)); } // e.g. SeatbeltSandbox::new()? on macOS
}
Defensive patterns

Strategy: validation

Validate before calling

// run before LandlockSandbox::new()
fn landlock_compiled_in() -> bool {
    cfg!(all(feature = "sandbox-landlock", target_os = "linux"))
}

Type guard

fn is_unsupported(e: &std::io::Error) -> bool {
    e.kind() == std::io::ErrorKind::Unsupported
}

Try / catch

match LandlockSandbox::new() {
    Ok(sandbox) => { /* use it */ }
    Err(e) if e.kind() == std::io::ErrorKind::Unsupported => { /* skip to next backend */ }
    Err(e) => return Err(e.into()),
}

Prevention

When it happens

Trigger: Calling LandlockSandbox::new() directly, or through an unconditional backend = "landlock" config mapping, in a build compiled without `--features sandbox-landlock` or on macOS/Windows. Also reached via LandlockSandbox::probe() in auto-detection code that does not first check cfg!.

Common situations: A plain `cargo build` of zeroclaw-runtime with default features (which omit sandbox-landlock); deploying a Linux binary that was built without the feature; running the test suite on a macOS dev machine; CI matrices that build every target uniformly.

Related errors


AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/2fd92c146f03df33. Report an issue: GitHub.