Sandboxed agent cannot distinguish sandbox ro-bind from a real read-only filesystem — suggest an in-sandbox identity marker

[boomzikazita]

现象

bwrap --ro-bind / / ... 下，agent 在 bash 内观测 findmnt / /proc/mounts 会看到根盘为 ro——这与内核因 ext4 错误 remount-ro 在现象上完全不可区分。

真实案例（今天刚发生）：agent 向工作区外的 Obsidian vault 写文件报 EROFS，据此误判为系统级文件系统故障并向用户发出紧急告警。排查后发现根盘始终正常（dmesg 无任何 ext4/remount 记录）——ro 只是沙箱命名空间视图。舱内没有任何直接信号能区分这两种情况，判别只能靠「内核日志无对应记录」这类间接证据。

影响

任何在沙箱 bash 里做系统诊断的 agent 都可能把沙箱视图当成系统真相，向外发虚警；更糟的是，真发生磁盘 remount-ro 时，沙箱内反而看不出来（/ 反正永远是 ro），故障会被沙箱视图掩盖。

判别参考（当前可用的 workaround）

沙箱内可用两步判别，无需出舱：

1. 在工作区内写测试文件（rw 绑定直通真实磁盘）：成功 → 磁盘可写，舱外 EROFS 纯属沙箱策略；也报 EROFS → 真实文件系统只读
2. 查 dmesg 是否有 EXT4-fs error / Remounting filesystem read-only：真 remount-ro 必然留痕，沙箱 ro-bind 一条内核记录都不会有

建议（按实现成本排序，任一即可）

1. bwrap 启动参数注入 --setenv DSH_SANDBOX_MODE=<policy>（复用现有 DSH_* 托管环境变量通道），agent 一条 echo $DSH_SANDBOX_MODE 即可自证观测位置
2. 沙箱拦截到工作区外路径的 EROFS 时，翻译为现有的 [sandbox: file access denied under <mode> mode] 格式，与 shim 拦截消息保持一致
3. 至少在 tool-bash 描述中补充：沙箱内 mount 表反映的是命名空间视图，工作区外路径的 EROFS 表示沙箱策略而非磁盘故障

环境

dsh 0.2.1-alpha.2，Linux，workspace-write 模式

[argszero]

The argv is exactly what you observed, and it is not an accident of one profile.

1. What the sandbox actually builds

bwrapProfileArgs() (packages/sandbox/sandbox-local/src/profiles.ts:17) is:

--ro-bind / / --dev /dev --unshare-pid --proc /proc --die-with-parent

workspace-write adds two mounts (:19-20): --tmpfs /tmp, then --bind <workspaceRoot> <workspaceRoot>. / stays read-only in both confining modes, and nothing in that package sets an environment marker — there is no --setenv anywhere under packages/sandbox/.

2. EROFS is the bubblewrap dialect, not a universal one

ConfinedArgv.denialSignatures (packages/sandbox/sandbox/src/index.ts:102-108) records the three dialects deliberately: EROFS under bwrap's read-only binds, EACCES under Landlock, EPERM under Seatbelt.

That matters for your report because Landlock keeps / in a readOnly grant (profiles.ts:35) with /tmp and the workspace read-write (:33) — so on a Landlock host, a write outside the workspace fails with EACCES, and the "root disk remounted read-only" misreading you describe does not arise. Your symptom is specific to hosts where the bwrap backend was selected; the reasoning about /proc/mounts is right, its scope is narrower than the report implies.

3. One correction: the model already has a mode signal

The report's statement that there is no direct signal available inside the sandbox is true for the shell and for syscalls, but not for the agent. sandbox-policy registers a sandbox:policy system-prompt context (packages/sandbox/sandbox-policy/src/index.ts:143), and its text under workspace-write (:47) names the session workspace explicitly, while the read-only text (:44-45) states that a modification cannot happen in the standing mode. What has no signal is a program reading /proc/mounts, a sub-agent that never sees the prompt, or a script whose output is judged later — which is the case worth fixing, and stating it that way changes which fix is right: a context section is what the model reads, an env marker is what a shell reads.

4. On your three suggestions

#1 (--setenv DSH_SANDBOX_MODE=<policy>) — yes, and it does not need a core change. SandboxProvider.confine(argv, policy) (packages/sandbox/sandbox/src/index.ts:177) returns the argv to spawn, and the caller's argv is appended after the profile's separator. So a wrapper can hand the consumer ['env', 'DSH_SANDBOX_MODE=workspace-write', 'DSH_SANDBOX_WORKSPACE=<root>', ...argv] and the env runs inside the sandbox namespace: the variable is visible to the command and to everything it spawns, with no edit to any backend. That shape is also the portable one — Landlock and Seatbelt launchers cannot set environment variables for the wrapped child at all, so an env prefix is the only spelling that works on all three backends.

#2 (translate EROFS into [sandbox: file access denied under <mode> mode]) — this is the one I would not do. That marker is appended by the executor only for denials the runner itself attributes (packages/shell/bash-sandbox/README.md:139; the text comes from sandboxDenialMarker(), packages/sandbox/sandbox/src/escalation.ts:71). A kernel EROFS cannot be attributed: a genuinely read-only filesystem mounted inside the namespace — a squashfs image, an ISO, a read-only block device — produces a byte-identical EROFS. Sniffing it inverts your own failure mode, turning a real filesystem fault into "denied by policy", and the user is told to escalate instead of investigating.

#3 (tool-description caveat) — cheap and correct. The denial marker is taught in the tool description; the mount-table caveat is not.

5. The half no marker can fix

When a real disk goes remount-ro, / inside the namespace is read-only either way. A marker that says "a sandbox is active" therefore makes the false negative slightly more likely, not less — the agent may now attribute every EROFS to the sandbox. So the marker answers "where am I observing from" and cannot answer "is the disk healthy". Your workaround is the right answer for the second half: write into the rw-bind workspace (:20), and treat dmesg (EXT4-fs error, Remounting filesystem read-only) as corroboration, accepting that dmesg may itself be permission-restricted inside the namespace.

Recommendation: #1 + #3 now, and keep #2 out. If it helps, the confine() wrapper in #1 can ship as a plugin — it needs no core change and works on all three backends — but the decision on the env name is yours; DSH_SANDBOX_MODE reusing the documented DSH_* channel seems right to me.

[argszero]

Recommendation ① from this thread is now a published plugin:

@argszero/dsh-sandbox-mode-marker 0.1.0 — https://github.com/argszero/dsh-sandbox-mode-marker

It shadows SandboxProvider.confine (one own-property write on the service instance, so every consumer is covered — bash-sandbox/src/index.ts:188, pwsh-sandbox:195, ptc-runtime-node:219/:190, ptc-runtime-python:1030, worktree/process.ts:54) and inserts an env assignment prefix at the start of the caller's own argv segment:

before:  bwrap --ro-bind / / … --die-with-parent -- bash -c 'npm test'
after:   bwrap … --die-with-parent -- env DSH_SANDBOX_MODE=read-only \
            DSH_SANDBOX_WORKSPACE=/work/repo DSH_SANDBOX_ENFORCEMENT=full bash -c 'npm test'

The program on the inside can then act on it:

if [ -n "$DSH_SANDBOX_MODE" ] && [ "$errno" = EROFS ]; then
  echo "the dsh sandbox blocked this write; the disk is fine" >&2
fi

Why the marker goes there and not at argv[0]

This is the one non-obvious decision, and it matters for a maintainer reading this thread. confine returns [runner, …runnerArgs, '--', …callerArgv] (sandbox-local/src/index.ts:330, :339), so argv[0] is the runner — and a consumer reads it as such: bash-sandbox/src/index.ts:106 records runnerProgram: facts.argv[0], and :120 hands the same element to isRunnerSpawnFailure to separate "the runner never started" (a SandboxUnavailableError) from "the command failed". An env at position 0 would reclassify every runner-start failure as a command failure, silently, and exactly when the sandbox is the thing that is broken.

So the assignments are placed by suffix equality: the caller's argv is known verbatim (it is argument 0), the wrapped argv must end with it, and that equality is the check that the placement is right. A backend that rewrote the caller's argv yields no placement and the call goes through unmarked rather than mis-marked. env execs in place, so pid, stdio and exit facts stay the program's own; the rest of the ConfinedArgv (enforcement, denialSignatures, runnerFailureRules) is spread through untouched, and a confine that fails still fails with its own reason and identity.

What it deliberately does not do

• No marker under danger-full-access. Consumers skip the capability in that mode (ptc-runtime-node:219, ptc-runtime-python:1030 test policy.mode === 'danger-full-access' before calling confine), so no call reaches any provider. Absence of the marker therefore means unconfined — either danger-full-access or a consumer that never confines. It never means read-only. Worth stating plainly anywhere this becomes a documented contract.
• Windows is skipped by default. The win32 chain has one rung (the ACL restricted-token runner, sandbox-local/src/index.ts:166) and a Windows image carries no env executable, so there is no argv-borne channel for an environment assignment. The plugin reports that at mount rather than mounting and marking nothing.
• EROFS is not translated. As I argued above, a real remount,ro produces the identical string, so turning it into "a sandbox denied this" converts a genuine failure into a false claim. The marker states intent (DSH_SANDBOX_MODE) plus the backend's own claim (DSH_SANDBOX_ENFORCEMENT=full|partial) and stops there.

Verification

Built against @deepseek-ai/cordis@4.0.4 and @deepseek-ai/dsh-sandbox@0.1.7-rc.2; the confine signature is identical on master (sandbox/src/index.ts:177).

• 81 tests. The witness spec mounts the shipped SandboxProvider base class on a real cordis Context, proves the shadow lands on the instance and covers a caller that never looked at the plugin, proves argv[0] is still the runner, and spawns a real child from the marked argv: the child finds DSH_SANDBOX_MODE=read-only in its own environment, and the same child spawned from the unmarked argv finds nothing.
• 30 mutation arms, 30 caught, 0 silent, 0 non-compiling, 1 declared equivalent.

If a maintainer would rather see this as a core capability than a plugin, the seam it needs is exactly one line in sandbox-local — --setenv on the bwrap rung, the Landlock launcher's own env channel, and a token-side equivalent for the ACL runner — and it would have to answer the same question this plugin answered: where in the runner's argv the assignments belong. Happy to align the plugin's variable names with whatever a core contract settles on; the names are a maintainer decision, not mine.

[argszero]

Publication status update: @argszero/dsh-sandbox-mode-marker@0.1.0 is on the registry, so suggestion ① from my earlier reply is now installable rather than hypothetical.

Verified through the registry's own version endpoint:

• dist.shasum = 415407b8ac16cbd78b3b2d4728fe4a10acbf2f92
• gitHead = 06c94d96e28807d00026f61c7043d1db6b14bc85
• source: https://github.com/argszero/dsh-sandbox-mode-marker

dsh plugin add @argszero/dsh-sandbox-mode-marker

It shadows the instance's SandboxProvider.confine and inserts env DSH_SANDBOX_MODE=<mode> in front of the caller's own argv, so the confined child reports which mode it is running under through its own environment — one execve replacing the next, no extra process.

Two details from building it that matter for anyone reusing the idea:

• The marker must come after the runner prefix, never at argv[0]. bash-sandbox decides "did the sandbox runner itself fail to start" from argv[0] (:106, :120); a marker in that position reclassifies a broken sandbox as a failing command, silently.
• It answers the identity question, not the observation one. Your report's harder half — that a --ro-bind / / sandbox cannot distinguish "the sandbox made this read-only" from "the filesystem was already read-only" from inside — stays open, and the earlier reply's reasoning about why suggestion ② would flip a real failure into a fake success still holds.