Windows 下 workspace-write 会永久改写工作区安全描述符（Low 完整性标签 + Everyone 删除拒绝），且无法回收

[yxAnswer]

Windows 下 workspace-write 会永久改写工作区安全描述符（Low 完整性标签 + Everyone 删除拒绝），且无法回收

写在前面

我用 dsh 0.2.1-rc.2（Windows 桌面版）开发一个 .NET 项目。项目的运行时数据放在工作区之外（D:\GrossingData），代码工作区是 D:\code\dev-SmartGrossing。

在一次会话之后，我发现工作区目录的安全描述符被改写了，而且这个改动在会话结束后依然存在，卸载也带不走，icacls 也删不掉。顺着源码查下去，确认这是 Windows 沙箱 workspace-write 的授权物化逻辑（grantWrite）写入的三条可继承项。

我不是来报"程序崩了"的——运行时确实没有崩。我想讨论的是：这层常驻改动对用户目录来说代价是不是太大了，有没有可能做成零残留或可撤销。 下面把我能证明的部分都列出来，方便判断。

环境

项	值
dsh	0.2.1-rc.2（desktop / Windows）
操作系统	Windows 10 Enterprise 22H2（10.0.19045）x64
账户	内置 Administrator
工作区	D:\code\dev-SmartGrossing（git worktree）
项目数据目录	D:\GrossingData（工作区之外）
触发条件	会话中任意一次真正被沙箱执行的命令（bash / pwsh 工具、终端面板都可以）

现象

1. 工作区根目录多出三条可继承的安全项，并已传播到整棵子树（含 bin、obj、.git）；
2. 工作区内的目录不能再以 GENERIC_ALL/FullControl 打开（对所有者、Administrators、SYSTEM 都是）；
3. 卸载 dsh 之后这些项仍然在，icacls 清理会报 ERROR_NONE_MAPPED（包的 README 里已经写明这一点）；
4. UI、日志、工具结果里没有任何提示。

需要区分一件事："程序写不了工作区外的数据"和"工作区 ACL 被改"是两个机制。 前者来自受限令牌（restricting SIDs + Low 完整性），后者是目录安全描述符。两者都来自同一个沙箱，所以体感上是同时出现的，但成因和解决办法不同。我一开始也把它们混为一谈了，后来逐项验证才分开。

最小复现

$ws = 'D:\code\dev-SmartGrossing'

# 1) 记录基线
icacls $ws

# 2) 在 dsh 里发起一次会执行命令的会话
#    （命令本身失败也没关系，例如 pwsh 起不来，授权物化在此之前已经发生）

# 3) 再看一次
icacls $ws

改动后会出现（解析结果，icacls 里等价显示为一条 DENY(DC)、一条按 SID 显示的未知账户、一条 Low 标签）：

类型	继承	掩码	受托方
DENY	CI	0x40 FILE_DELETE_CHILD	S-1-1-0 Everyone
ALLOW	OI|CI	0x110156	S-1-4-297152335-144657661
SACL: MANDATORY_LABEL	OI|CI	NO_WRITE_UP	S-1-16-4096（Low）

证据 1：这条 SID 就是 dsh 按工作区路径算出来的

按 packages/sandbox/sandbox-windows-acl/src/workspace-sid.ts 的算法：

const d = require('crypto').createHash('sha256').update('D:\\code\\dev-SmartGrossing').digest()
const a = d.readUInt32LE(0) % (2 ** 30 - 1) + 1
const b = d.readUInt32LE(4) % (2 ** 30 - 1) + 1
console.log(`S-1-4-${a}-${b}`)   // => S-1-4-297152335-144657661

和工作区里那条 ACE 的 SID 完全一致。可以排除是系统、杀软或其他软件留下的。

证据 2：写入时间点 = 会话第一次执行沙箱命令

D:\code\dev-SmartGrossing 的 ctime 变为 2026-10-20 08:34:49，正好是本会话第一次工具调用被沙箱执行之前的一刻。作为对照，同一台机器上 D:\GrossingData 的 ctime 仍停在 10-19，没有被写过。

也就是说，改动只落在"工作区根 + 每会话私有临时目录"，和项目数据目录无关。

证据 3：对自己进程的影响（同机实测）

用携带工作区能力 SID 的令牌，对工作区根发起目录打开：

dir READ_CONTROL        (0x20000)    => OK
dir FILE_DELETE_CHILD   (0x40)       => DENIED err=5
dir GENERIC_ALL         (0x10000000) => DENIED err=5

FILE_DELETE_CHILD 单独请求都被拒绝，说明 Everyone 那条 deny 在第一次访问检查就生效；GENERIC_ALL 包含 0x40，所以工作区内任何目录的 FullControl 打开都会返回 ERROR_ACCESS_DENIED。这一点和 2026-09-19-windows-acl-mandatory-integrity-confinement.zh.md 里写的"授权根内目录的 FullControl 打开被拒绝，这是无法避免的代价"是一致的，不是我这台机器的个例。

影响

1. 不可回收的残留。 包的文档明确写了工作区 ACE 和标签"按设计常驻，绝不撤销"，手工 icacls 清理会 ERROR_NONE_MAPPED，只能靠重建目录回收。对于把工具装在公司机器、项目目录又要长期保留的人来说，这个成本不太容易接受。

2. 改变了用户自己进程的行为。 目录 FullControl 打开被拒；靠父目录 FILE_DELETE_CHILD 的删除路径被移除（文件自身 DACL 没有 DELETE 时，用户自己的进程也删不掉）。

3. 安全面副作用。 Low 标签比 dsh 生命周期更长，同一用户下任何 Low 完整性进程都能写这个工作区。

4. 完全不可见。 改动发生在后台，用户只能靠 icacls 自己发现。对比只改子进程令牌的工具（Codex 一类），它不会在你目录上留下任何东西，所以用户很难把因果对上。

5. 调试时非常容易误判。 受限令牌下，任何试图写工作区外数据的程序都会以应用层错误失败，而这些错误都不指向沙箱。我遇到的例子是 ASP.NET + EF Core + SQLite，库在 D:\GrossingData\API\DB\app.db：

   SQLite Error 14: 'unable to open database file'.
      at Microsoft.EntityFrameworkCore.Migrations.HistoryRepository.Exists()
   

   同时 Serilog 的 File sink 静默失败（控制台有日志，文件一行都没有），因为 File sink 拿不到写权限时不报错。两条线索看起来都像数据库损坏或文件锁，实际原因是"数据在工作区之外，被沙箱拒绝"。这一条不是 bug，但可诊断性几乎为零。

源码定位（0.2.1-rc.2）

• 授权物化：packages/sandbox/sandbox-windows-acl/src/acl.ts → grantWrite()，一次 SetNamedSecurityInfoW 完成三项编辑；
• 作用范围：packages/sandbox/sandbox-windows-acl/src/index.ts 只对 writableDirs 和每会话私有临时目录调用 grantWrite，没有恢复/撤销路径（revokeWrite 只处理可回收的临时目录授权）；
• 常量：packages/sandbox/sandbox-windows-acl/src/win32-abi.ts（GRANT_MASK = 0x110156、CONTAINER_INHERIT_ACE、WinLowLabelSid）；
• 设计取舍：.agents/notes/implemented/feature/2026-09-19-windows-acl-mandatory-integrity-confinement.zh.md。

这是 0.2.x 才有的行为

2026-08-08-windows-acl-restricted-token-sandbox.zh.md 描述的初版只加能力 SID 的允许 ACE，没有 Low 标签、没有 Everyone 删除拒绝。那一版对普通进程完全惰性，用户基本无感。

2026-09-19 为修复 issue #4581（cmd /c del 能删工作区外的文件）追加了标签和拒绝项，笔记里明确写了：

"早前版本已授权的工作区会在下次供给时补上拒绝项。"

所以：同一个项目、同一台机器，0.1.x 用着没事，0.2.x 开始出现残留和目录权限变化。这和我自己的经历一致，也说明它是一次有意的行为变更，而不是偶发故障。

想讨论的几个问题

1. 常驻是必须的吗？ 能否在每会话私有临时目录下创建一个指向工作区的 junction/合成根，把三项编辑和 cwd 都落在合成根上，令牌仍然只携带合成根的 SID？这样工作区本身完全不动，会话结束删掉合成根即可。代价大概是路径会变、有些工具对 junction 敏感，想听听你们对可行性的判断。
2. 能否提供官方回收手段？ 现在 icacls 已经回收不了（ERROR_NONE_MAPPED），用户没有任何自救路径。是否值得提供类似

   dsh sandbox acl status --workspace <path>
   dsh sandbox acl reset  --workspace <path>
   

   的命令，精确移除这三条并重新传播子树？诊断脚本既然已经会备份 DACL，回收逻辑的增量应该不大。
3. 首次修改前是否应该有一次显式同意？ 提示里说明将要修改的对象、影响范围、以及"卸载后仍然存在"，并记住选择；UI 里提供"查看/清除沙箱权限"。
4. 拒绝面能否更可诊断？ 越界写/删失败时，在工具结果或终端里标注 sandbox: denied 及原因；文档里列出典型症状（SQLite CANTOPEN、File sink 静默失败、构建产物删除失败、目录 FullControl 打开失败）。
5. 文档能否把边界写得更靠前？ 比如在 workspace-write 的说明里加一句"运行时数据必须位于工作区内，否则被沙箱运行的程序会以应用层错误失败"，并附上 whoami /groups 的判别方法（看是否出现 Low 完整性级别和 S-1-4-…）。

我目前的规避方式

• 依赖工作区外数据的程序（API、客户端）不在 dsh 的终端里启动，放在普通终端或 IDE 里跑；
• 确实要让 dsh 跑的时候，会话切到完全权限（但不会清掉已经存在的残留）；
• 长期看，如果常驻改动不可撤销，我大概只能调整工作区布局，或者换工具。

附：另一个独立的 Windows 问题（可以另开讨论）

在这台机器上，pwsh 工具 100% 以 0xC0000142 失败，连 Get-Location 都跑不起来：

exitCode: 3221225794 (0xC0000142 STATUS_DLL_INIT_FAILED)
stdout/stderr: 空

同机 bash 工具、文件读写工具正常。README 把"以 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程在 DLL 初始化期死亡"列为已知限制，但这里是每一次都失败，Windows 上的 PowerShell 能力实际不可用。不确定是否和本机控制台/会话环境有关，或者是否应该在 spawn 侧回退为继承控制台。

最后

如果需要，我可以提供：工作区根的完整 ACE/SACL 解析、改动前后的 icacls 输出、以及在一台干净目录上做最小复现的录屏。

谢谢。

[ttttqb]

用UE引擎工程也碰到了

[mrhan1993]

Low 完整性标签是吧, 可以去掉

用 pwsh

$root = 'workdirFullPath'

icacls $root /reset /C

Add-Type -Namespace SecFix -Name Native -MemberDefinition @'
[DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern uint SetNamedSecurityInfo(string name, uint type, uint info,
    IntPtr owner, IntPtr group, IntPtr dacl, IntPtr sacl);
'@

# 1 = SE_FILE_OBJECT          （对文件系统对象操作）
# 0x10 = LABEL_SECURITY_INFORMATION（只动完整性标签，不碰 DACL）
# sacl = NULL                  （空 SACL ⇒ 移除标签）
$rc = [SecFix.Native]::SetNamedSecurityInfo($root, 1, 0x10,
    [IntPtr]::Zero, [IntPtr]::Zero, [IntPtr]::Zero, [IntPtr]::Zero)
"rc = $rc   # 0 = 成功"

另外还有一个简单的办法, 重建目录. 就是把目录里边东西复制走, 新建目录复制回去