[Bug] Windows ACL 沙箱：Low 完整性标签只落在"授权后新建"的子项，已存在的子目录永远被拒写；Windows ACL sandbox: the Low integrity label only reaches children created after the grant, so pre-existing subdirectories stay unwritable

[NOBU1999]

环境

项	值
DSH	官方桌面版 0.2.0-rc.2
系统	Windows 11 x64，profile = desktop
工作区	D:\dsh-agent（已使用约一个月，根目录下已有 17 个子文件夹）
相关包	@deepseek-ai/dsh-sandbox-windows-acl / dsh-sandbox-policy

现象

• 工作区根目录可写：直接在 D:\dsh-agent\ 下新建文件成功。
• 子目录写入一律 Access denied，例如：
  • D:\dsh-agent\.temp\
  • D:\dsh-agent\FGOBondApp\release\
• 读取与列举子目录正常，只有写入被拒。
• 该状态反复出现：手工修好后可写，随后又整体退回。已复现两次，间隔约 5 小时。

与 #401 / #423 的归因不同：capability ACE 一直在

#401 / #423 归因于「capability ACE 永不补授」。但逐字节对比 SDDL 后，能写与不能写的目录，那条写 ACE 实质完全相同：

能写（backups）:
D:AI(D;CIID;DT;;;WD)(A;OICIID;0x110156;;;S-1-4-527487773-558809585)(A;ID;FA;;;BA)…

不能写（docs，修复前）:
D:AI(D;CIID;DT;;;WD)(A;OICIID;0x110156;;;S-1-4-527487773-558809585)(A;ID;FA;;;BA)…

0x110156 即 DeleteSubdirectoriesAndFiles, Write, Delete, Synchronize——两条都在，且都是 ID（继承而来）。

唯一的差别是强制性完整性标签。 这一点用"同一时刻、同一工作区、逐目录对照"得到 17/17 的完全对应：

	顶层目录
带 Low 标签（5 个）	.acl-repair-20261001、backups、docs、FGOBondApp、scratch
不带标签（12 个）	.gradle-home、.npm-cache、.temp、.tmp、.tmp-engine、android-keys、baidu-player-backup-20260911-105257、data、plugins、scripts、symbols-elev、需要验证

同一工作区、仍受沙箱限制时实测的被拒清单：

.gradle-home, .npm-cache, .temp, .tmp, .tmp-engine, android-keys,
baidu-player-backup-20260911-105257, data, plugins, scripts, symbols-elev, 需要验证

12 个对 12 个，逐一吻合；带标签的 5 个正是当时全部可写的那 5 个。

同一次测量中，这 17 个目录的写 ACE 逐条相同：

docs     Allow DeleteSubdirectoriesAndFiles, Write, Delete, Synchronize  继承=True
         (A;OICIID;0x110156;;;S-1-4-527487773-558809585)
plugins  同上（逐字节一致）
backups  同上（逐字节一致）
scratch  同上（逐字节一致）
data     同上（逐字节一致）

被拒的目录上那条 ACE 一条都不缺。

因果实验（充分性）：给一个被拒的目录补上标签、不动 ACE →

$ icacls "D:\dsh-agent\docs" /setintegritylevel (OI)(CI)Low
$ icacls "D:\dsh-agent\docs"
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
$ Set-Content "D:\dsh-agent\docs\probe.txt" x    → 成功（此前同一路径为 Access denied）

必要性（因果）：在沙箱生效的状态下，对同一个能写目录只改标签、完全不动权限条目：

步骤	docs 的完整性标签	写入结果
起点	Low Mandatory Level:(OI)(CI)(NW)	能写
只改标签	Medium Mandatory Level:(OI)(CI)(NW)	Access denied
改回	Low Mandatory Level:(OI)(CI)(NW)	能写

每一步都同步记录了该目录的写 ACE，前后逐字节一致：

(A;OICIID;0x110156;;;S-1-4-527487773-558809585)

同一条命令内还以"无标签目录"作阴性对照（plugins / scripts / data 始终被拒），用以确认测量环境确实处于沙箱之下、而不是脱离沙箱后的假阳性。

结论：低完整性标签既充分（补上即可写）、又必要（改成 Medium 即被拒）；而那条 capability ACE 在所有状态中始终存在且未变 —— 它不是判别因素。

机制（对照本包源码注释）

@deepseek-ai/dsh-sandbox-windows-acl 中 grantWrite 的注释自述：每次授权在一次 SetNamedSecurityInfoW 里做三件事——

1. the capability-SID allow ACE
2. a Deny ACE that removes the ambient FILE_DELETE_CHILD right from the world SID
3. and a Low no-write-up mandatory label（buildLowLabelAcl）

而 buildLowLabelAcl 的注释是：

Build the Low mandatory label applied with every write grant: … inheriting to subcontainers and objects so later children carry the same label.

关键在 "later children"：

• ① ② 通过 DACL 正常继承（所以每个子目录上都能看到那条 S-1-4-… 写 ACE）；
• ③ 只可靠地落在授权之后创建的子项上。对授权时已存在的子目录，Windows 并不会把该标签下推。

沙箱进程运行在低完整性（Low IL）下，Windows 的强制完整性检查（no-write-up）会拒绝它写入没有标签的对象。因此：

权限条目怎么改都没有用——因为缺的不是权限条目，是标签。

这也解释了另一个现象：diagnose-windows-sandbox-acl.ps1 对本例判定为 PRECONDITION（它只写 DACL），补上 WRITE_OWNER 后依然不可写。

复现与验证

# 1) 现状：无标签，写入被拒
icacls "D:\dsh-agent\docs"
Set-Content "D:\dsh-agent\docs\probe.txt" x          # → Access denied

# 2) 补上同一个 Low 标签
icacls "D:\dsh-agent\docs" /setintegritylevel (OI)(CI)Low
Set-Content "D:\dsh-agent\docs\probe.txt" x          # → 成功

# 3) 对整棵工作区补标签
icacls "D:\dsh-agent" /setintegritylevel (OI)(CI)Low /T /C /Q
#    → 17/17 个顶层目录全部可写

# 4) 但随后 DSH 再为某个会话授权后重测
#    → 可写数从 17/17 回落到 5/17，回落的正是丢掉标签的那些目录

第 4 步的两个观测点（同一工作区、同一 DSH 进程未重启）：

时间	可写顶层目录
补标签后立刻	17 / 17
约 5 小时后（期间切换并使用过另一个既有会话）	5 / 17

带标签的 5 个全部可写，其余 12 个全部被拒——对应关系精确。

影响面

• 任何"已经存在若干子目录"的工作区都会被命中。新建工作区不明显（授权时子项与标签同时产生）。
• 用户侧的直观感受是「只能改工作区根这一层，子目录全挡」，很容易被误判为"策略变了"或"权限被人改坏了"——实际是标签问题，且权限工具查不出来。
• 唯一可行的用户侧对策是反复手工补标签，或把会话切到 danger-full-access。

建议的修法

1. grantWrite 对已存在的子树做一次显式标签补授；关键在于当前的"标签已存在就跳过整树重传播"的优化，会让已经缺标签的子目录永远修不回来。
   注释里提到的 label skip the eager full-tree re-propagation 正是这个优化的入口。
2. 或者让限制令牌的写判定**同时接受"父目录带可继承标签"**的情形。
3. 至少：grantWrite 在检测到子目录缺标签时给出可诊断的告警/日志，而不是让用户只看到裸的 Access denied。
4. 建议提供官方修复入口，例如 dsh sandbox repair --workspace <path>，一键重打标签并报告结果。

备注

• 本文所有结论均在上述环境实测；SDDL 与 icacls 输出为直接抓取，未做改写。
• 关于"授权循环会冲掉标签"这一步：观测事实是"修好后可用 → 一段时间后整体退回"，两次复现一致；具体是哪一条代码路径触发，我没有定位到，留给维护者判断。

---

English summary

Symptom. On Windows with the official desktop build (0.2.0-rc.2), writes into subdirectories of an existing workspace fail with Access denied, while writing into the workspace root succeeds. Reads and listings work. The condition recurs: after a manual repair the workspace is fully writable, then reverts.

This is not a missing capability ACE. Byte-wise SDDL comparison of a writable and a non-writable subdirectory shows the S-1-4-… write ACE (0x110156) present and inherited in both. The only difference is the mandatory integrity label:

writable:      Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
not writable:  (no label)

Mechanism. grantWrite in @deepseek-ai/dsh-sandbox-windows-acl applies three edits per grant: the capability-SID allow ACE, a Deny for FILE_DELETE_CHILD, and a Low no-write-up mandatory label, documented as "inheriting to subcontainers and objects so later children carry the same label." The first two inherit through the DACL; the label only reliably reaches children created after the grant. Because the sandboxed process runs at Low integrity, Windows' no-write-up check then denies writes into unlabeled directories — regardless of their permissions.

Repro / verification.

1. icacls "<dir>" → no Mandatory Label, write denied.
2. icacls "<dir>" /setintegritylevel (OI)(CI)Low → the same directory becomes writable immediately.
3. icacls "<workspace>" /setintegritylevel (OI)(CI)Low /T /C /Q → 17/17 top-level directories writable.
4. Later (after DSH granted again for another existing session) the count reverted to 5/17, exactly the directories that had lost the label. Reproduced twice.

diagnose-windows-sandbox-acl.ps1 classifies this as PRECONDITION and repairs the DACL only, so it cannot fix it — the missing piece is not a permission entry.

Suggested fix. Have grantWrite explicitly re-apply the label across the existing subtree (the current "skip the eager full-tree re-propagation when the label is present" optimization leaves already-unlabeled children permanently broken), or accept an inheritable label on the parent in the write check; at minimum, warn when a granted directory's children lack the label. An official dsh sandbox repair --workspace <path> entry point would help users recover.