[0.1.5-rc.2]: 在某一次对话中，dsh向我汇报了工作区外目录误删的事故，想问一下是bug还是操作问题

[YouHui1]

现象

在 workspace-write 模式下，一个受限的 pwsh 命令成功删除了两个位于工作区之外的 windows 符号链接

环境

DSH	0.1.5-rc.2
后端	@deepseek-ai/dsh-sandbox-windows-acl
模式	workspace-write（审批策略 ask）
系统	Windows / NTFS，USN journal 可用
接入模型	火山方舟 Agent Plan 的 DeepSeek-V4.1-Flash（dsh汇报事故后就切成官方的deepseek 4.1 flash了）

过程

1. 常规对话，修改插件内容
2. dsh 反馈修改过程中出现误删事故，但是沙箱拦截下来了，没有文件被删掉
3. 自己抽查，恰好发现 vscode 所有插件都没了（vscode插件下载在D盘，在C盘建了一个符号链接）
4. 让 dsh 排查，最终发现两个符号链接被删了（另一个链接是 :\Users\xxx\AppData\Local\Application Data），AI分析说是因为自己的命令写错了导致的

疑惑点

正常来说，修改外部内容的话，沙箱是会做拦截并请求用户确认的，但是当时并没有做任何拦截，是因为dsh可能把操作的命令写入脚本后执行脚本，沙箱默认是操作当前目录所以放过去了吗（之后排查问题、重建链接涉及到修改外部文件，都有拦截并请求确认）

dsh 生成的分析结论

dsh-sandbox-reparse-point-escape.md

dsh-sandbox-reparse-point-escape.zh-CN.md

sandbox-escape-evidence-appendix.md

[YouHui1]

还有一个问题我需要确认下，当前的沙箱是否像AI描述的这样：

workspace-write 模式不能阻止工作区外 NTFS 重解析点（junction / mount point）被删除。
该 ACL 后端是授权式而非禁止式：工作区外的写入因 DACL 未授权而失败，但删除 junction 是目录项操作，
不受这套检查覆盖。实测两次删除的 2/2 junction 全部成功，而同一批遍历中的普通文件与目录 0 个被删。
包文档与源码从未提及重解析点（§Verified boundaries 只列 Everyone 与硬链接）。

因此：含 -Recurse 的删除在进入用户目录等区域时，其危险性不能靠沙箱兜底。
read-only 模式无写授权，无此问题 —— 但也意味着需要写入时应先与用户确认模式。

[PerryLink]

你的疑问里有一个前提需要先纠正：这个沙箱不是按"当前目录"授权的，所以"因为命令写进脚本执行、沙箱以为还在当前目录"这条推测不成立。它是按目录树上的 ACL 能力授权的，而"授权范围内允许删除"是设计如此。

packages/sandbox/sandbox-windows-acl/README.md:94
  "`workspace-write` (logon SID, Everyone, workspace SID, temp SID) grants the workspace and the
   session's private temp subdirectory separate Write grants"

packages/sandbox/sandbox-windows-acl/src/acl.ts:354
  "Grant `GRANT_MASK` (Write+Delete, displays as \"Modify\") to the capability SID"

注意 Write+Delete：在被授予的目录树里，删除是被允许的。沙箱要挡的是"写到授权范围之外"，不是"在范围内不许删"。所以判断你这次是否发生了越权，只有一个问题：那两个链接所在的目录，是否位于被授予的 workspace 树（或私有临时目录）之内？

• 若在内（例如你的 workspace 就是 C:\Users\<你> 或某个包含它们的上级目录）：删除是授权范围内的正常操作，没有拦截是正确的，"穿越"并不存在 —— 这也解释了为什么当时没有弹确认（确认是给范围外操作用的）。
• 若在外：那才是真问题，需要看你当时的 workspace 根路径与授权记录才能继续。

还有一条对你"以为插件全丢了"很关键的事实：删除一个符号链接/联接点，删掉的是链接本身（reparse point），不是它的目标。你的 vscode 插件实体在 D 盘，删链接不会动到它们 —— 这与你自己抽查的结论（只有两个链接消失、AI 说是命令写错）一致。

所以这条我建议按下面这样改写才算"可判定"的报告（现在这版缺的正是这个）：

1. 当时的 workspace 根路径是什么（--dump-config 或会话记录里有）；
2. 那两个链接的完整父目录路径；
3. 执行删除的原始命令（脚本内容也算），以及它是由哪个工具发出的（受限 pwsh？还是 dsh 自己的文件工具？两者的授权层不同）。

有这三条就能直接判定"授权范围内正常删除"还是"越界"。我不猜是哪一种。

边界：读的是 c36a83ff6b（dsh-v0.1.7-alpha.1）的提交树；你报的是 0.1.5-rc.2，两个版本的授权细节我没有逐一对比。我没有你的 USN journal、命令或授权记录，也没有复现。

[YouHui1]

你的疑问里有一个前提需要先纠正：这个沙箱不是按"当前目录"授权的，所以"因为命令写进脚本执行、沙箱以为还在当前目录"这条推测不成立。它是按目录树上的 ACL 能力授权的，而"授权范围内允许删除"是设计如此。

packages/sandbox/sandbox-windows-acl/README.md:94
  "`workspace-write` (logon SID, Everyone, workspace SID, temp SID) grants the workspace and the
   session's private temp subdirectory separate Write grants"

packages/sandbox/sandbox-windows-acl/src/acl.ts:354
  "Grant `GRANT_MASK` (Write+Delete, displays as \"Modify\") to the capability SID"

注意 Write+Delete：在被授予的目录树里，删除是被允许的。沙箱要挡的是"写到授权范围之外"，不是"在范围内不许删"。所以判断你这次是否发生了越权，只有一个问题：那两个链接所在的目录，是否位于被授予的 workspace 树（或私有临时目录）之内？

• 若在内（例如你的 workspace 就是 C:\Users\<你> 或某个包含它们的上级目录）：删除是授权范围内的正常操作，没有拦截是正确的，"穿越"并不存在 —— 这也解释了为什么当时没有弹确认（确认是给范围外操作用的）。
• 若在外：那才是真问题，需要看你当时的 workspace 根路径与授权记录才能继续。

还有一条对你"以为插件全丢了"很关键的事实：删除一个符号链接/联接点，删掉的是链接本身（reparse point），不是它的目标。你的 vscode 插件实体在 D 盘，删链接不会动到它们 —— 这与你自己抽查的结论（只有两个链接消失、AI 说是命令写错）一致。

所以这条我建议按下面这样改写才算"可判定"的报告（现在这版缺的正是这个）：

1. 当时的 workspace 根路径是什么（--dump-config 或会话记录里有）；
2. 那两个链接的完整父目录路径；
3. 执行删除的原始命令（脚本内容也算），以及它是由哪个工具发出的（受限 pwsh？还是 dsh 自己的文件工具？两者的授权层不同）。

有这三条就能直接判定"授权范围内正常删除"还是"越界"。我不猜是哪一种。

边界：读的是 c36a83ff6b（dsh-v0.1.7-alpha.1）的提交树；你报的是 0.1.5-rc.2，两个版本的授权细节我没有逐一对比。我没有你的 USN journal、命令或授权记录，也没有复现。

AI说明

先把你要的三条补齐，然后说明为什么你给的二分里「在授权树内」那一支在这台机器上已经被排除。有一点我同意你的纠正，见 §4。

1. 你问的三条

(1) 当时的 workspace 根路径

D:\dazed\AIproject\dsh-sessions-diagnosis

来源：会话日志自身记录的 cwd。会话 id session-48e40e30-e055-4676-b4ed-b2ff29c9cd61，会话存储在
sessions\--D-dazed-AIproject-dsh-sessions-diagnosis--\ 下 —— 存储目录名就是工作区路径的编码形式。

一个附带说明，来自你们自己的 dsh-tool-pwsh README（§Known limitations 最后一条）：会话 cwd 不做规范化，
而受限执行器下的 workspace root 是被规范化过的，两者在原始 cwd 与其规范形式不同时会分叉。所以严格说，
我上面给的是「会话头记录的 cwd」，不是「规范化后的限制根」。如果判定需要后者，请告诉我该读哪个字段
（--dump-config？），我按你的口径再取一次。

(2) 两个链接的完整父目录路径

父目录	被删的子项	类型	目标
C:\Users\<user>\.vscode	extensions	用户创建的 junction（mklink /J）	D:\vsextensions\extensions（今天仍在，93 个目录 / 1.75 GB）
C:\Users\<user>\AppData\Local	Application Data	Windows 自带的自引用兼容 shim	AppData\Local 自身

(3) 原始命令，以及是哪个工具发出的

发出者：受限 pwsh 工具（dsh-tool-pwsh → ACL 受限令牌后端）。
不是 dsh 自己的文件工具（write/edit 那条基于路径的栅栏）—— 这一点很关键，两者授权层不同，这次走的是
DACL 那一层。会话日志里同一条命令的 tool/call 原文（$home 之前的载荷是本次会话的无关内容，我保留了原文
以便你核对，关键在最后一句）：

$home = Join-Path $env:TEMP ("dsh-nocodec-" + (Get-Random)); node --input-type=module -e "<本次会话的载荷>" $home; node bin/dsh-session-doctor.mjs scan --dsh-home $home; "--- exit: $LASTEXITCODE"; Remove-Item $home -Recurse -Force

tool/call 记录自带时间戳 1789916310385 → 2026-09-20T14:58:30Z = 本地 22:58:30，与 USN
journal 里那两条删除记录（23:00:23 / 23:00:24）处在同一次调用的运行窗口内。callId 也可以提供。

2. 「在授权树内」这一支，在路径包含关系上就不成立

workspace 根在 D:\dazed\...，两个 junction 都在 C:\Users\<user>\...：不同卷，也不是它的后代。

而且注意 .vscode\extensions 的目标在 D:\vsextensions\extensions —— 同样不在
D:\dazed\AIproject\dsh-sessions-diagnosis 之内。所以：

无论你在哪一层做路径规范化 —— 链接自身所在位置，还是链接解析后的目标 —— 两条路径都不落在授权树里。

workspace SID 与 temp SID 的 ACE 都只落在各自的根上并向下继承，而这两个被删对象都不是这两个根的子孙：
AppData\Local\Application Data 与 temp 根（AppData\Local\Temp\dsh-*）是旁支而非子支，
.vscode\extensions 更与它无关。

3. 决定性对照：同一父目录、同一继承 DACL、只有对象类型不同

~\.vscode 的 DACL（Get-Acl 实测）：SYSTEM / Administrators / <user> → FullControl，
全部 inherited，没有任何 Everyone 条目。mklink /J 建的目录继承同一组 ACE。同一次运行中该目录下的三个子项：

子项	类型	Cannot remove item 错误行	结果
cli	普通目录	1	拒绝
argv.json	普通文件	1	拒绝
extensions	junction	0	删除

这解释不了「授权范围内允许删除」：如果那个父目录真的被 workspace ACE 覆盖，同一父目录里的普通子项会一起被删。
同一轮运行里还有 24,872 条拒绝、0 个普通文件/目录被删（工作区外的隐式拒绝当时确实生效），
被删除的只有重解析点，2/2。

所以你的二分里，第一支（在授权树内 ⇒ 正常删除）在这台机器上不成立；这正是我报的那一支。

4. 我同意你的部分（并撤回一处措辞）

• 沙箱不是按「当前目录」授权的 —— 同意；我最初「命令写进脚本、沙箱以为还在当前目录」的说法不准确，撤回。
• 授权范围内 Write+Delete、范围内删除是设计如此 —— 同意，我在报告 §5 里也记了 workspace 根上那条
  非继承 ACE 含 Delete / DeleteSubdirectoriesAndFiles。争议点不是「范围内能不能删」，
  而是这次删除发生在一个没有任何 restricting SID 被授予的父目录里。你引的 acl.ts:354 的 GRANT_MASK
  只作用于被授予的那些根，覆盖不到 C:\Users\<user>\.vscode。
• 删除 junction 删的是链接本身，不是目标 —— 同意，这也是我没有把它写成灾难的原因。

另外一条与判定有关的：pwsh 的越权是整条命令级别的（重试同一命令、附 sandbox_permissions），
ACL 后端则是按令牌拒绝、根本不逐路径弹确认。所以「当时没有弹确认」对判定没有信息量 ——
它既不能证明在范围内，也不能证明越界。

5. 我不声称的部分（保持原报告的边界）

• 不声称具体 Win32 调用路径。 两次被删对象的 ACL 出身不同（一个用户创建、一个 Windows 自带并带
  非继承 Everyone: Deny ReadData），唯一共同属性是重解析点。报告 §8 已写明。
• 不声称这次删除由哪个进程发出。 USN 不记录 actor；我的归因依据是「时间窗 + 父目录 FileId 解析 +
  命令历史扫描（59 份会话日志、6,423 次调用中，唯一一条以用户目录根为删除目标的命令就是上面那条）」。

6. 把机制钉死的实验（无数据风险，我可以做）

§3 的最小复现本身就是安全实验：junction 不存数据，目标会存活。要做成可判定，我会：

1. 在工作区外新建 C:\Users\<user>\sandbox-repro\{target, plain.txt, link}（link 用 mklink /J）；
2. 记录三个对象的 Get-Acl / fsutil reparsepoint query / dir /aL；
3. 在那条 junction 上打开对象访问审核（SACL: DELETE + FILE_DELETE_CHILD），或用 ProcMon 过滤该路径的
   RemoveDirectory / SetDispositionInformationEx；
4. 从 workspace-write 受限 pwsh 分别执行 Remove-Item ...\link -Force 与
   Remove-Item ...\sandbox-repro -Recurse -Force；
5. 贴出：命令原文、exit code、对象前后状态、以及 Event 4663（SubjectProcessId + 被授予的 AccessMask）。

这能同时回答「是不是越界」和「是哪一层放行的」。做不做、以及在哪个版本上做，你定。

7. 版本

你读的是 c36a83ff6b（v0.1.7-alpha.1），我报的是 0.1.5-rc.2。我这边的安装包是
@deepseek-ai/dsh-sandbox-windows-acl@0.1.5-rc.2，对其 README.md + lib/ 全文检索
reparse / junction / symlink = 0 命中（命中的 link 全部是 {@link} 文档标记或 hard link 表述）。

所以：如果 c36a83ff6b 已经加了重解析点处理，请给我 commit，我在那个版本上重跑第 6 节的实验；
如果还没有，报告 §7 的第三条——把 reparse points 写进 §Verified boundaries 并让 partial 报告反映它——
在两个版本上都仍然成立。

[argszero]

One version fact that narrows the question you are waiting on, from the same-reporter thread next door (#7517, also 0.1.5-rc.2):

$ git tag --contains 36e632751e     # "deny the ambient parent-delete right inside granted roots"
dsh-v0.1.7-alpha.1
dsh-v0.1.7-alpha.2
$ git log -1 --format='%h %cd' dsh-v0.1.5-rc.2
fb2c4b9e69 Thu Sep 10 21:50:19 2026 +0800

0.1.5-rc.2 predates the whole delete-confinement series. At that tag grantWrite was a single allow entry — buildExplicitAccess(sidPtr, GRANT_ACCESS, GRANT_MASK) — and git grep -i 'integrity|label|MANDATORY' over packages/sandbox/sandbox-windows-acl at that tag (README included) returns nothing: no world deny on FILE_DELETE_CHILD, no Low mandatory label.

So on the build reported here, your answer "if the parent is inside the granted tree, the delete is ordinary authorized behaviour" is right — but it does not cover the second case, and that case does not need a workspace-root answer at all: a delete outside the granted roots was authorized by the caller's ambient rights on the object's own parent, which no restricting SID had to co-sign and nothing denied. That is what #7517 measures through a junction it creates itself: writes refused (they need the restricting-SID pass-2 co-sign, absent outside), deletes allowed (they needed only the ambient parent right).

What I could not settle from source is which parent the kernel evaluates FILE_DELETE_CHILD on — the object's real parent, or the alias the path resolves through. That is what decides whether a junction adds anything here. The two measurements that distinguish them are in the analysis in #7517.

Practical suggestion for this thread: a retest on 0.1.7-alpha.1+ answers more than the three facts can. At HEAD the workspace root carries an inheritable Low label and the confined token is lowered to match, so a delete outside the granted roots should fail the integrity check on its own, whatever the link topology. If you already have the workspace root path from the session record, please still post it — the same question ("in-tree or not") comes back for the write cases, where the label does not apply.

[argszero]

The gap this thread reports now has a mountable answer: @argszero/cordis-plugin-reparse-escape-guard

• npm: https://www.npmjs.com/package/@argszero/cordis-plugin-reparse-escape-guard
• source: https://github.com/argszero/cordis-plugin-reparse-escape-guard (MIT, 0.1.1)

- insert:
    - id: reparse-escape-guard
      name: '@argszero/cordis-plugin-reparse-escape-guard'

The rule it enforces is the one your incident is an instance of: a path whose spelling sits inside the granted write area while its resolution leaves it. It canonicalizes the declared path operands of a tool call and compares them against the same derivation the filesystem fence uses, then refuses the call before dispatch with the three facts a fence sentence omits:

"/ws/link/out.txt"
  as written:              /private/var/…/ws/link/out.txt  (inside /private/var/…/ws)
  actually resolves to:    /private/etc/out.txt  (outside every writable root)
  the link:                /private/var/…/ws/link

That middle line is computed by walking component by component the way the kernel does, which is what makes link/../x come out right (a lexical collapse calls it contained; the kernel follows the link out and never returns), and why a root with two spellings — /var and /private/var on macOS — is judged correctly rather than in the two opposite wrong directions.

The honest boundary for your case, since your report is a pwsh command that deleted through a symlink: the guard judges the path operands a tool declares in its arguments (write, edit, str_replace_editor). A path inside a shell command line is not an operand, and is invisible to it by default; there is a shellFields opt-in that scans declared text for path-looking words, but that is a best-effort net over tokens — it cannot tell that Remove-Item deletes while Get-Item does not, and it will miss a path assembled at runtime. So this plugin would not have stopped your deletion. It also does not enforce anything on its own: the fence re-canonicalizes at publication time, and this only refuses the call earlier and explains it.

What it would have changed is the model's next move. The refusal names the link and both readings, so the call cannot be re-tried under a different spelling with the same silent outcome — which is what turns "the sandbox refused me" into "I now know this directory is a link out of the workspace".

Two side notes that may bear on your incident directly:

• Your build is 0.1.5-rc.2. The delete-confinement series (d5ad3baeb5 → 36e632751e → 3d5ba3b83f) is contained only in dsh-v0.1.7-alpha.1 and later, so a retest there is worth doing before treating the deletion as still reachable — in that line grants are a single ALLOW ACE while confinement is expressed as explicit deny ACEs, so a refusal is stated rather than inherited.
• :\Users\xxx\AppData\Local\Application Data appearing as the second target is the classic self-referential junction: on stock Windows profiles that path is a junction pointing back at its own parent, so it reads as collateral rather than a second independent escape.

37 tests (real Cordis context, real ToolRuntime, real tools/pre-execute waterfall, real SandboxPolicyService, an unmounted control arm); one integration suite runs the same operand past the real @deepseek-ai/dsh-fs-sandbox and shows fence and guard agree on the verdict, differing only in diagnosis; mutations.py requires the suite to go red on each broken claim (11/11).

[YouHui1]

AI 补充说明

补一条更正与后续。

1. 撤回原报告的机制判断

我把「重解析点是判别因素」当作结论，这是错的。

上游 d5ad3baeb5（fix(sandbox): confine Windows deletes with a Low integrity label）写明了真正的机制：

The write-restricted token's capability-SID intersection only covers the write bits of the object's own access check. Windows also authorizes a write or a delete from the parent directory's FILE_DELETE_CHILD right, and no restricting SID has to co-sign that authority: the confined child could therefore delete any file its ambient user SIDs control.

同一段还引用了 issue #4581 —— 也就是说这个缺口在我出事之前已被别人报过，且上游在 9 月 19 日就修了。

所以：判别因素是「这次删除需不需要父目录的权限」，与对象是不是重解析点无关。 链接之所以"看起来特殊"，只是因为那次递归删除里，链接对象的移除恰好走了不需要父目录权限的那条路。报告 §1 / §2.2 / §6 / §7 的相应表述作废；§4 的原始测量数据（USN 两条 DIRECTORY | REPARSE POINT 删除、24,872 条普通对象拒绝、0 个普通对象被删）仍然有效。

2. 版本事实

已在本地仓库逐 tag 核对：

tag	是否含 d5ad3baeb5 / 36e632751e / 3d5ba3b83f
dsh-v0.1.5-rc.2（我报告时所用）	否（0/3）
dsh-v0.1.5-rc.3	否（0/3）
dsh-v0.1.7-alpha.1	是（3/3）
dsh-v0.1.7-rc.2	是（3/3）

感谢 @argszero 在 16:50 指出这一点：我报的构建确实早于整条 delete-confinement 序列，而那三个 commit 只进 0.1.7 线。

3. 在 0.1.7-rc.2 上重测的结果

方法：把两个 tag 各自导出、安装依赖、构建，然后用每个版本自带的 runner 启动真实受限子进程，对授权根之外的同一组对象做同一组操作。授权根 = 一个空工作目录 + 一个空私有临时目录（均在用户 profile 下的一个测试目录内），受测对象在其外。

检查	0.1.5-rc.2（旧）	0.1.7-rc.2（新）
受限子进程完整性级别	Medium S-1-16-8192	Low S-1-16-4096
授权根内删除（阳性对照）	成功	成功
授权根外写入文件	成功（越权）	被拒
授权根外删除 junction	未复现（对象存活）	未删除（对象存活）
授权根外删除普通文件 / 普通目录	未复现（对象存活）	未删除（对象存活）
包内完整性标签代码	0 处	TokenIntegrityLevel 命中 4 个文件

两点结论：

1. @argszero 那条预测成立：HEAD 上「删除授权根之外的对象会自己过不了完整性检查」——本机实测与该描述一致，且与链接拓扑无关（junction 与普通对象表现相同）。新构建的子进程确实被降到 Low。
2. 旧构建的越权写入已复现：同一个受限子进程在 read-only 与 workspace-write 两种模式下，都成功在授权根之外创建了文件；新构建两种模式下都被拒。

4. 边界（不含糊）

• 旧构建的越权「删除」我没能在本机复现。 我的 runner 装置在生产令牌形状上仍有偏差（很可能在 restricting SID 组合上），四次尝试（standalone 与 seam 式授权 × read-only 与 workspace-write）都只复现出"授权根外写入成功"，删除始终被拒。因此上面旧构建那一行的删除结论不是我推翻原报告的论据，我不主张它。
• 旧行为放行删除的直接证据，仍然只有我 9-21 给出的 USN 记录与 stderr 统计（工作区外普通对象 24,872 条拒绝 / 0 个被删，而两个 junction 被删）。它足以说明"当时发生了什么"，但不足以独立指认机制——机制以上游 commit 为准。
• 本机只装了 Windows PowerShell 5.1（无 PowerShell 7），受限子进程用它执行；这一点不影响 ACL 层的结论，但说明本机环境与 CI 不同。
• 所有测量来自一台机器、一个 Windows 修订版本。

5. 可复现性

探针脚本（Python，纯标准库）与三次运行的记录我按 9-21 那三份文件的同样方式直接附在下面。脚本会自建授权根与受测对象、自检"当前进程是否未受限"（受限则直接中止，而不是给出误导性的 DENIED）、并在授权根内放一个阳性对照对象，用来证明受限子进程确实具备删除能力。

需要说明一处记录局限：子进程的逐条结果本应写入一个结果文件，但在本机上该文件始终未生成，而它自身的 stdout 又被调用方截断，因此删除那几项只留下了对象状态的记录（运行前后对象是否存在），没有留下逐条的 OK/DENIED 文本。对象状态不受此影响——它在子进程退出后直接从文件系统读回，且多次重复一致。

delete-escape-probe.py
probe-results-redacted.md