monty-fs

Host-side filesystem mounts for Monty, the sandboxed Python interpreter.

Provides MountTable, which maps virtual POSIX paths inside the sandbox (e.g. /mnt/data) to real host directories with configurable access modes (read-write, read-only, or in-memory overlay).

The monty interpreter crate never performs filesystem I/O itself — sandboxed code suspends with an OsFunctionCall describing the requested operation, and a host holding a MountTable services it via MountTable::handle_os_call. Keeping that I/O in a separate crate means the interpreter (and worker artifacts built from it, such as the wasm worker) contain no host-filesystem code at all.

Confinement is structural rather than a check: each mount holds a cap_std::fs::Dir opened at mount time, and every operation runs relative to that descriptor, so .., symlinks, and directories swapped mid-operation cannot reach outside it. path_security.rs is left with path policy alone — normalization, null-byte rejection, and length limits.

Each mount has a configurable aggregate memory budget that defaults to 100 MB. Retained in-memory overlay data and transient filesystem results share that budget; oversized operations return MemoryError before an unbounded read.

Monty crates

• monty — the core interpreter: Python parser, bytecode VM, and sandbox.
• monty-types — the shared boundary data types (values, exceptions, OS calls, resource limits) hosts use without linking the interpreter.
• monty-fs — host-side filesystem mounts: maps virtual sandbox paths to real host directories. this crate
• monty-runtime — the monty binary: REPL, file runner, and subprocess worker mode.
• monty-pool — an elastic pool of crash-isolated monty worker subprocesses.
• monty-proto — the protobuf wire protocol spoken between pool parents and workers.
• monty-type-checking — type checking of sandboxed code, powered by ty.
• monty-typeshed — the trimmed typeshed stubs describing the stdlib subset Monty implements.
• monty-macros — the proc macros behind monty's argument parsing.