Struct ProcessBackend 

pub struct ProcessBackend { /* private fields */ }

Subprocess-based sandbox backend.

Executes code by spawning child processes with tokio::process::Command. Enforces timeout via tokio::time::timeout and environment isolation via env_clear(). Optionally enforces filesystem and network isolation when a SandboxEnforcer is configured via with_sandbox().

Example

use adk_sandbox::{ProcessBackend, SandboxBackend};

let backend = ProcessBackend::default();
assert_eq!(backend.name(), "process");

With OS-level sandbox

use adk_sandbox::{ProcessBackend, ProcessConfig, SandboxPolicyBuilder, get_enforcer};

let enforcer = get_enforcer()?;
let policy = SandboxPolicyBuilder::new()
    .allow_read("/usr/lib")
    .allow_read_write("/tmp/work")
    .build();

let backend = ProcessBackend::with_sandbox(
    ProcessConfig::default(),
    enforcer,
    policy,
);
assert!(backend.capabilities().enforced_limits.filesystem_write_isolation);

Implementations

impl ProcessBackend

pub fn new(config: ProcessConfig) -> Self

Creates a new ProcessBackend with the given configuration.

The result is IsolationClass::SubprocessOnly until an enforcer and policy are attached; see ProcessBackend::isolation.

pub fn isolation(&self) -> IsolationClass

How much isolation this backend applies.

Check this before treating execution as sandboxed. Without an enforcer and a policy, execution is subprocess isolation only.

pub fn with_sandbox( config: ProcessConfig, enforcer: Box<dyn SandboxEnforcer>, policy: SandboxPolicy, ) -> Self

Creates a new ProcessBackend with OS-level sandbox enforcement.

All executions through this backend will be sandboxed with the given policy. The enforcer wraps commands with platform-specific restrictions (Seatbelt on macOS, bubblewrap on Linux, AppContainer on Windows).

Each execution runs in a fresh scratch directory holding its source file and compiler output. That directory becomes the working directory and is granted read-write on top of the policy, since the enforcers deny every path the policy does not name.

If different tools need different policies, create multiple ProcessBackend instances.

impl ProcessBackend

pub fn toolchain_env() -> Vec<(String, OsString)>

Variables a compiler needs to find its own tools.

rustc shells out to a platform linker and resolves it through the environment. The MSVC linker also reads LIB to find the Windows and C runtime libraries. With the environment cleared it cannot link at all, so compilation gets a small platform-specific allowlist. On Windows, missing values are discovered from the installed Visual Studio Build Tools and Windows SDK.

This widens what the compile phase can see compared with the run phase. An OS enforcer is what constrains it; see ProcessBackend::isolation.

Callers that invoke rustc themselves apply this after env_clear(), so compile-time macros such as env! and option_env! see only these variables.

Example

use adk_sandbox::ProcessBackend;

let environment = ProcessBackend::toolchain_env();
assert!(environment.iter().all(|(key, _)| key != "OPENAI_API_KEY"));

Trait Implementations

impl Debug for ProcessBackend

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for ProcessBackend

fn default() -> Self

Returns the “default value” for a type.

impl SandboxBackend for ProcessBackend

fn name(&self) -> &str

Returns the backend name (e.g., "process", "wasm").

fn capabilities(&self) -> BackendCapabilities

Returns the capabilities and enforced limits of this backend.

fn execute<'life0, 'async_trait>( &'life0 self, request: ExecRequest, ) -> Pin<Box<dyn Future<Output = Result<ExecResult, SandboxError>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait,

Executes code in isolation according to the request parameters.