Sandbox writableRoots hardcoded — no way to add extra writable dirs for SDK toolchains / 沙箱可写根目录无法附加(SDK工具链)

[0gl20shk0sbt36]

Sandbox writableRoots is hardcoded — cannot add extra writable directories for SDK toolchains

沙箱可写根目录硬编码 — 无法附加额外可写目录(SDK 工具链场景)

中文 / Chinese

问题: 会话沙箱的可写目录(writableRoots)被硬编码为三处: workspaceRoot + /tmp + os.tmpdir()(dsh-sandbox/lib/index.js 的 writableRoots 实现), 没有"附加可写目录"配置项。

场景: 在最小化工作区(workspaceRoot = 项目目录)下, 使用 SDK 编译(flutter / go / dart 等):

• PUB_CACHE/TMPDIR 可以用环境变量重定向到项目内, 但 SDK 自身的 cache 路径是写死的(如 flutter 的 $FLUTTER_ROOT/bin/cache/engine.stamp / engine.realm, 由 flutter 脚本 pwd -P 推导真实 SDK 路径), 无法用 env 重定向
• 结果是: 编译命令在工作区内的写全部放行, 但 SDK 自身 cache 的写入被沙箱拒绝(即使 mode 已是 workspace-write)
• 现有 workaround 都别扭: ①把 SDK 复制进项目(浪费磁盘/每项目一份); ②每次走 sandbox_permissions 审批升级; ③软链无效(flutter 解析真实路径, landlock 按 inode 检查)

请求: 在 sandbox-policy(或 fs-sandbox)配置中支持附加可写根目录(如 extraWritableRoots: ["/home/user/flutter"]), 让用户在保持工作区最小化的前提下, 放行特定工具链目录的写入。这会比"复制 SDK 进项目"和"每次审批升级"都更实用。

English / English

Problem: The sandbox's writable roots (writableRoots) are hardcoded to exactly three entries — workspaceRoot + /tmp + os.tmpdir() (see the writableRoots implementation in dsh-sandbox/lib/index.js). There is no configuration for additional writable directories.

Scenario: With a minimal workspace (workspaceRoot = the project directory), compiling with an SDK (flutter / go / dart etc.):

• PUB_CACHE / TMPDIR can be redirected into the project via env vars, but the SDK's own cache path is hardcoded (e.g. flutter's $FLUTTER_ROOT/bin/cache/engine.stamp / engine.realm, resolved by flutter's pwd -P to the real SDK path), so env redirection does not cover it
• Result: writes inside the workspace pass, but the SDK's own cache writes are denied by the sandbox (even with mode = workspace-write)
• Existing workarounds are all awkward: ① copy the SDK into the project (disk waste / one copy per project); ② use sandbox_permissions escalation on every compile; ③ symlinks don't help (flutter resolves the real path, landlock checks inodes)

Request: Support additional writable roots in sandbox-policy (or fs-sandbox) configuration, e.g. extraWritableRoots: ["/home/user/flutter"], so users can allow specific toolchain directories without enlarging the workspace root. This would be far more practical than copying SDKs into projects or approving every compile.

[ChristophSchmidpeter]

Another concrete use case: multi-repository development.

I often work on projects split across sibling repositories where two repositories need to be writable, while other sibling repositories should remain intentionally non-writable.

With the current single-root workspace-write policy, starting DSH from either repository makes the other one read-only. Starting it from their common parent grants write access too broadly.

Support for additional writable roots would solve this cleanly while preserving least privilege, e.g.:

workspaceRoot: /home/user/src/project/repo-a
extraWritableRoots:
  - /home/user/src/project/repo-b

[NateScarlet]

Confirming the Windows case, and offering a workaround that is available today.

The Windows rung does not need a mount set

You traced the hardcoded three-entry writableRoots in dsh-sandbox/lib/index.js. On Windows the enforcement is different in a way that helps here: workspace-write does not give the child a set of binds, it mints a WRITE_RESTRICTED token whose restricting SIDs include a capability SID derived from the canonical workspace path (workspaceWriteSid). Windows does two access checks and grants write only where both pass, so any directory whose DACL carries an inheritable allow-write ACE for that SID is writable — without the workspace root containing it, and without touching DSH's config.

So for the SDK-toolchain case ($FLUTTER_ROOT/bin/cache, or a Go build cache outside the project) the ACL route succeeds where the symlink route fails: there is no path canonicalization to defeat, because the grant is on the target directory itself.

Verified

Windows 11, session in workspace-write, workspace C:\Workspaces\scripts:

computed workspaceWriteSid = S-1-4-1022062912-955841020
Get-Acl <workspace> -> S-1-4-1022062912-955841020
    Write, Delete, DeleteSubdirectoriesAndFiles, ContainerInherit, ObjectInherit

I granted a git directory outside the workspace and then git add + git commit succeeded with no escalation prompt — objects and refs written outside the workspace root. Controls:

• A write to C:\Windows\Temp in the same session still failed (UnauthorizedAccessException), so this is not a case of the sandbox silently being off.
• Under read-only the standing ACE stays inert: that mode's restricting list carries no capability SID, so pass-2 grants nothing.

Limits, stated plainly

• Bound to one workspace. The SID comes from the workspace path, and DSH's restricting list is fixed — the runner accepts only its own --write-sid / --temp-write-sid. There is no supported way to add a third SID, so a grant made for workspace A does nothing for workspace B. Start a session from their common parent, or re-grant per workspace.
• Case-sensitive derivation. workspaceWriteSid hashes the path as given, no case folding, so the grant must use the canonicalized path or it silently names an identity no token carries.
• Not visible to the model. This is the same asymmetry your request is meant to remove — the model does not know those directories are writable, so it may refuse or ask for escalation unnecessarily. A line in AGENTS.md papers over it; only the upstream feature fixes it.
• Windows only. No effect on bwrap / Landlock / Seatbelt.

Implementation

https://github.com/NateScarlet/Scripts/blob/dcae2371b3c57a08615e3732f4d4bd68e8861fb6/specialized/dsh_sandbox_grant.py

Includes a test asserting byte-parity against DSH's own workspaceWriteSid, because the failure mode of a mismatched SID is silent — the ACE is written and simply never matches.

I still think the declarative extraWritableRoots is the right answer; this is an ops-side stopgap for Windows until then, not a substitute.