Problem / Motivation
The rootfs writable layer is capped by --writable-layer-size, but read-write host mounts have no size limit.
Writes go straight to the host filesystem: they bypass CubeCoW, so the scheduler's disk accounting never sees them, and the mount descriptor (hostPath / mountPath / readOnly) has no quota field. Files also survive
sandbox teardown, so nothing gets reclaimed.
A sandbox with a read-write mount can fill the host disk in under a minute:
import json
from cubesandbox import Sandbox
mounts = json.dumps([
{"hostPath": "/data/shared/demo", "mountPath": "/mnt/out", "readOnly": False},
])
with Sandbox.create(template=TEMPLATE_ID, metadata={"host-mount": mounts}) as sb:
sb.commands.run(
"fallocate -l 500G /mnt/out/fill.bin "
"|| dd if=/dev/zero of=/mnt/out/fill.bin bs=1M"
)
Killing the sandbox doesn't free the space — only a host-side rm does. If /data/shared sits on the same
filesystem as the system / Cubelet, a full disk takes down the whole node (snapshots, new sandbox creation, logs). Even on a dedicated volume, all tenants on the node share it, so one sandbox filling it breaks everyone else's mounts with ENOSPC.
This needs no exploit — it's just the documented "Output persistence" use case. Any platform handing sandboxes to untrusted users (agent workloads are easy to prompt-inject into running such a command) is exposed.
Proposed Solution
An optional size limit on the mount descriptor, e.g. sizeBytes, enforced by Cubelet at mount time. Over-limit
writes inside the guest fail with ENOSPC. If the backing filesystem can't enforce it, reject the mount at
create time rather than silently allowing it.
XFS project quotas (auto-assigned per mount) look like the cheapest enforcement path, since passthrough writes are accounted at the host fs layer regardless of which process writes.
Per-mount usage in sandbox info and some metrics would also help operators see this coming.
Alternatives Considered
- readOnly mounts — blocks all writes, doesn't work for output persistence
- Path prefix allowlist — already exists, bounds where you can write, not how much
- Periodic cleanup (current docs advice) — helps with slow accumulation, can't stop a live attack
- Operator-side quotas (XFS project quota per owner dir, dedicated LV for /data/shared) — what deployments
have to do today, each reinventing it, with nothing visible to the platform
Additional Context
Problem / Motivation
The rootfs writable layer is capped by --writable-layer-size, but read-write host mounts have no size limit.
Writes go straight to the host filesystem: they bypass CubeCoW, so the scheduler's disk accounting never sees them, and the mount descriptor (hostPath / mountPath / readOnly) has no quota field. Files also survive
sandbox teardown, so nothing gets reclaimed.
A sandbox with a read-write mount can fill the host disk in under a minute:
import json
from cubesandbox import Sandbox
mounts = json.dumps([
{"hostPath": "/data/shared/demo", "mountPath": "/mnt/out", "readOnly": False},
])
with Sandbox.create(template=TEMPLATE_ID, metadata={"host-mount": mounts}) as sb:
sb.commands.run(
"fallocate -l 500G /mnt/out/fill.bin "
"|| dd if=/dev/zero of=/mnt/out/fill.bin bs=1M"
)
Killing the sandbox doesn't free the space — only a host-side rm does. If /data/shared sits on the same
filesystem as the system / Cubelet, a full disk takes down the whole node (snapshots, new sandbox creation, logs). Even on a dedicated volume, all tenants on the node share it, so one sandbox filling it breaks everyone else's mounts with ENOSPC.
This needs no exploit — it's just the documented "Output persistence" use case. Any platform handing sandboxes to untrusted users (agent workloads are easy to prompt-inject into running such a command) is exposed.
Proposed Solution
An optional size limit on the mount descriptor, e.g. sizeBytes, enforced by Cubelet at mount time. Over-limit
writes inside the guest fail with ENOSPC. If the backing filesystem can't enforce it, reject the mount at
create time rather than silently allowing it.
XFS project quotas (auto-assigned per mount) look like the cheapest enforcement path, since passthrough writes are accounted at the host fs layer regardless of which process writes.
Per-mount usage in sandbox info and some metrics would also help operators see this coming.
Alternatives Considered
have to do today, each reinventing it, with nothing visible to the platform
Additional Context