ExSandbox.Mechanism.Docker (ExSandbox v1.0.1)

Copy Markdown View Source

A sandbox is one container, managed through the docker CLI.

Why this exists beside ExSandbox.Mechanism.Beam

Beam confines a process with the host's kernel -- cgroup v2, user and mount namespaces, bwrap. On macOS none of those exist, so ExSandbox.Capability.check/1 reports every gating name unavailable and the gate refuses before provision/1 is reached. That refusal is correct and it leaves a developer on a Mac with nowhere to run tenant code.

This mechanism brings its own kernel. The Linux VM behind Docker Desktop has cgroup v2 (docker info reports cgroup=2, driver cgroupfs), so the caps are real limits inside the container regardless of what the host can do -- which is why it declares ExSandbox.Mechanism.constructed_capabilities/0 and the host probe is asked only about what is left over.

What it does NOT claim, and the measurement behind that

⚠️ No :disk_quota. MEASURED 2026-08-28, Docker Desktop engine 27.4.0, linux/arm64, storage driver overlayfs:

docker run --rm --storage-opt size=16M alpine \
  sh -c 'dd if=/dev/zero of=/big bs=1M count=64; df -h /'
 67108864 bytes copied, exit=0
 overlay  54.8G  30.4G  21.6G  59% /

64 MB written into a nominal 16 MB quota, exit 0. docker create --storage-opt size=1G also returns success. The option is accepted and ignored -- the same shape as 005 R9b, where a cap was invoked and did not hold.

So a sandbox under this mechanism can fill the host filesystem, and that is stated rather than hidden. Requiring :disk_quota instead would refuse on every overlayfs host, which is every Docker Desktop for Mac -- the host this mechanism exists to serve -- and a mechanism that refuses everywhere is not a safer mechanism, it is no mechanism.

The image comes from template_ref

ExSandbox.Sandbox.t/0 names owner_ref, mechanism_ref and context as opaque, and template_ref deliberately not: it is the one field a mechanism is meant to interpret as "what to create this from". Here it is a container image reference. A sandbox that names no template gets alpine:3, which is a floor for a workspace mount, not a recommendation.

Summary

Functions

Whether a container runtime answered on this host, right now.

Where workspace_path is mounted inside the container.

Functions

runtime_available?()

@spec runtime_available?() :: boolean()

Whether a container runtime answered on this host, right now.

⚠️ Asked of the daemon, not of the executable. Docker Desktop leaves its client on PATH with the VM stopped, so finding the binary answers a question nobody asked -- the same shape as Capability.check(:filesystem_confinement) finding sandbox-exec on macOS and reporting a confinement the launch does not build.

⚠️ Deliberately not cached. A host acquires a container runtime by the operator starting one, and the caller for this is a refusal message telling them to do exactly that; an answer cached at boot would keep saying "install a runtime" to somebody who just did.

workspace_mountpoint()

@spec workspace_mountpoint() :: String.t()

Where workspace_path is mounted inside the container.