Support First-Class Shared Filesystem Mounts for HPC Sandboxes

Problem Statement

Summary

Add first-class support for declaring shared filesystem mounts when creating an OpenShell sandbox.

This is important for HPC-style workloads where tools, datasets, source trees, scratch spaces, and outputs often live on shared filesystems such as NFS, Lustre, GPFS, BeeGFS, or other site-managed storage.

Today, OpenShell can express filesystem access policy inside a sandbox, but it also needs a supported way to declare how external shared paths are mounted into the sandbox in the first place.

Scope

This feature targets Unix-style operating systems only — specifically Linux on shared-compute hosts. Windows hosts and Windows-style filesystem semantics are out of scope. macOS is not a target either; this is a Linux HPC feature.

Related issue:

• #1393 discusses rootless / NFS hosts and the difficulty of using Docker, Podman, MicroVMs, or Kubernetes in large HPC-like environments.

Problem

HPC workloads are often file-centric:

• Toolchains may be installed on shared read-only paths.
• Input datasets may live on shared project storage.
• Job outputs may be very large and unsuitable for copy-in / copy-out workflows.
• Users expect jobs to operate directly against scheduler-provided work directories and shared scratch.
• Shared filesystems are usually managed by the site, not by the sandbox runtime.

OpenShell policies can describe read_only and read_write paths, but there should also be a first-class mechanism for binding shared host paths into deterministic sandbox paths.

Proposed Design

Requested behavior

Allow sandbox creation to declare one or more shared filesystem mounts.

Example shape:

mounts:
  - source: /shared/tools
    target: /hpc/tools
    mode: read_only
    required: true

  - source: /project/foo/datasets
    target: /hpc/datasets
    mode: read_only
    required: true

  - source: /scratch/${USER}/${JOB_ID}
    target: /hpc/workspace
    mode: read_write
    required: true

The corresponding filesystem policy would then apply inside the sandbox:

filesystem_policy:
  read_only:
    - /hpc/tools
    - /hpc/datasets
  read_write:
    - /hpc/workspace
    - /tmp
landlock:
  compatibility: hard_requirement

Requirements

• Support bind-mounting host/shared filesystem paths into deterministic sandbox paths.
• Support read-only and read-write mount intent.
• Support required: true behavior: if a required source path cannot be mounted or accessed, sandbox startup should fail.
• Preserve expected UID/GID behavior for users on shared filesystems.
• Work without per-user admin privileges.
• Work on locked-down Linux compute hosts where adding new daemons or orchestrators may be undesirable.
• Compose cleanly with OpenShell filesystem_policy and Landlock enforcement.
• Emit clear errors/logs when a mount is missing, inaccessible, skipped, or cannot be protected.

Suggested solution

• Add a mounts: block to the sandbox policy schema with the shape shown under Requested behavior.
• Implement mount setup in the Supervisor's pre-exec phase, after policy load but before the target process is launched, so that a mount failure aborts startup cleanly.
• Reuse the existing filesystem_policy / Landlock machinery to enforce read-only vs. read-write semantics over the bound paths — i.e., the mount declares the binding, and filesystem_policy continues to declare the access policy.

Alternatives Considered

Bubblewrap

Agent Investigation

No response

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request

Start at the sandbox policy schema and the Supervisor's pre-exec phase described in the proposal. Trace the existing filesystem_policy and Landlock machinery, then determine how required mount failures and read-only/read-write intent should be represented and reported. Done means Linux sandbox creation supports declared shared mounts with clean failure handling and compatible policy enforcement.