[Bug Report] Windows：非提权启动时 workspace-write 沙箱 provisioning 必然失败，且留下残破 ACL 导致永久无法自愈

[xiechara64-coder]

[Bug Report] Windows：非提权启动时 workspace-write 沙箱 provisioning 必然失败，且留下残破 ACL 导致永久无法自愈

摘要

Windows 10/11 上，若 dsh 以非提权（过滤令牌）方式启动，workspace-write 沙箱在 provisioning 阶段即失败：

SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\DSH)

由于失败发生在 provisioning，任何命令都执行不了（连 Get-Date 都会失败）——工具调用在命令真正启动前就被沙箱配置挡下。

更麻烦的是，失败的 grantWrite 会在 workspace root 上留下残破的安全描述符：三段编辑只落地了第一段（且是降级形态）。而 grantWrite 的幂等跳过条件要求三段全部齐备，因此跳过永远不成立 → 之后每次 provisioning 都重走 mergeAndApply 并同样失败。该 workspace 从此无法自愈，即使之后用足够权限重启 dsh 也无效；本机最终是手工授予特权 + 提权重启才恢复的。

复现步骤（Windows 10 build 19041 · dsh 0.1.7-rc.2 · npx 安装）

1. 以管理员账户登录 Windows（UAC 保持默认开启）。
2. 打开非提权 PowerShell——不要用"以管理员身份运行"。
3. 启动 dsh（文件策略 workspace-write，审批策略 ask）：

   cd D:\DSH
   npx @deepseek-ai/dsh web

4. 执行任意工具命令（哪怕只是 Get-Date）。

预期：沙箱 provisioning 成功，命令正常执行。
实际：每条命令都失败于
SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\DSH)，
且工具结果里给出的 escalation 路径（retry with sandbox_permissions …）无法救场——因为失败在 provisioning，不在命令自身的文件操作上。

环境

• OS：Windows 10，build 19041（20H2 / 2004），NTFS 固定卷 D:
• Shell：Windows PowerShell 5.1.19041.6456
• dsh：@deepseek-ai/dsh 0.1.7-rc.2（npx 启动）
• 启动上下文：非提权用户 shell（过滤令牌）
• UAC：EnableLUA=1、ConsentPromptBehaviorAdmin=5（默认配置，未做任何策略改动）
• workspace：D:\DSH，位于 NTFS 固定卷，owner 即启动用户

故障时刻的令牌状态：

whoami /all →
  Mandatory Label\Medium Mandatory Level
  BUILTIN\Administrators    Group used for deny only        ← 过滤令牌

whoami /priv →
  SeShutdownPrivilege            Disabled
  SeChangeNotifyPrivilege        Enabled
  SeUndockPrivilege              Disabled
  SeIncreaseWorkingSetPrivilege  Disabled
  SeTimeZonePrivilege            Disabled

令牌中完全没有 SeRelabelPrivilege，也没有 SeSecurityPrivilege。

根因（源码定位，0.1.7-rc.2）

grantWrite 在一次 SetNamedSecurityInfoW 调用里施加三段编辑：

1. capability-SID 的授予 ACE；
2. world SID 的 FILE_DELETE_CHILD 拒绝；
3. Low 强制完整性标签。

完整性标签存放在对象的 SACL 中，写入它需要 SeRelabelPrivilege（或 SeSecurityPrivilege）。过滤 / 非提权令牌两者皆无 → 整个调用返回 ERROR_ACCESS_DENIED (5)，且因为是单次原子调用，三段编辑一段都不落地。

dsh-sandbox-windows-acl 自身的文档注释把这个问题当成已被 owner 权限解决：

The directory must be owned by the caller AND grant WRITE_OWNER
(the label lives in the SACL; owner-implicit rights cover only READ_CONTROL and
WRITE_DAC) — a Full-control workspace satisfies both.

该论断对非受限令牌成立，但对非提权令牌不成立：owner 与 WRITE_DAC 都满足，标签写入仍然失败，因为缺的是特权而非 DACL 权限。这应该就是缺口所在。

实测佐证（同一非提权令牌下）：

• 仅写 DACL（.NET Set-Acl 添加 ACE）→ 成功
• icacls <dir> /setintegritylevel (OI)(CI)L → Access is denied

即失败被精确孤立在标签 / SACL 那一段编辑上。

为什么无法自愈（与 #423 的区别）

grantWrite 的跳过条件要求三段同时成立：

if (oldAcl !== null && labelAcl !== null && hasExactGrant(oldAcl, sidPtr)
    && hasExactDeny(oldAcl, worldSidPtr) && hasExactLabel(labelAcl, lowLabelSidPtr)) { return; }

失败后实测的 workspace ACL：

D:\DSH S-1-4-433454674-798464005:(OI)(CI)(S,DC)     ← ACE 存在，但缺 W，且是降级形态
       BUILTIN\Administrators:(I)(F)
       ...（其余为继承条目）...

只有第 1 段以残缺形态落地，第 2 段与第 3 段完全缺失 → 跳过条件永久不可满足 → 每次 provisioning 都重跑并同样失败。provider 的 workspaceGrants 内存缓存只在单个 server 生命周期内有效。

与 #423 的差异：#423 的前提是 root 上已存在精确 ACE（grantWrite 成功过、跳过正常命中），问题在"后来新增的子目录拿不到补授"。本报告的前提是 root 上的 ACE 从一开始就是残缺的、grantWrite 从未成功过，因此跳过永远不命中。两者症状（file access denied / 永久失效）相似，但触发条件与代码路径不同——#423 是"跳过了该补的"，本报告是"根本没建成、于是永远重试"。

与 #3434 的差异：#3434 处理的是授权成功时首次 eager 传播阻塞事件循环的性能问题。本报告是授权本身失败，属于另一种失败模式。

影响

• 在默认正确配置的 Windows 10 上，只要 dsh 不是以提权方式启动，workspace-write 策略就完全不可用。
• 失败发生在命令启动之前，工具结果里除裸 Win32 5 外没有任何可操作诊断，产品内也没有任何关于特权要求的提示。
• 残缺 ACL 使故障跨重启持续，看起来像永久性回归，而不是"启动上下文不对"。
• 每次工具调用都退化为人工审批。

Workaround（本机已验证有效）

1. 在提权 shell 中给账户授予特权：

   $k = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeRelabelPrivilege"
   New-Item -Path $k -Force | Out-Null
   New-ItemProperty -Path $k -Name "<account>" -Value "<account>" -PropertyType String -Force

2. 以提权 shell 重新启动 dsh。 特权只会进入新建提权登录的令牌；重新以非提权方式启动仍然失败。

完成后 grantWrite 通过，三段编辑齐全，命令执行恢复正常且不再弹审批。
（另一种临时绕过：把会话切到 danger-full-access，它会完全跳过 materializeAclGrant——但代价是失去该防护。）

建议修复（供讨论）

1. 提前检测并明确报错（成本近乎为零，且不影响性能）。
   Windows 上以 workspace-write 启动时，先校验令牌是否持有（或可获取）SeRelabelPrivilege / SeSecurityPrivilege；若否，在启动阶段就抛出可操作的错误，指明缺失的特权与两条解法（授予特权 + 提权重启，或改用 danger-full-access），而不是从深处 provisioning 调用里冒出一个裸 Win32 5。

2. 不要让残缺授权永久锁死（但必须绕开 # Bug + fix: Windows 大工作区首次 workspace-write 授权同步遍历 ACL 整树，事件循环冻结数分钟 #3434 的性能陷阱）。
   建议不要"重放 grantWrite"——据 # Bug + fix: Windows 大工作区首次 workspace-write 授权同步遍历 ACL 整树，事件循环冻结数分钟 #3434 实测，SetNamedSecurityInfoW 携带 OI|CI 会触发整树 eager 传播（4,332 文件 2,773.7 ms；182,053 文件 >120 s），重放会重新引入该冻结。更合适的做法是让跳过判定容错：把"ACE 存在但缺 W / 缺 deny / 缺标签"视为"需要重做"，并且只在该情况下才重新 apply——这样一次特权就绪的重启即可修复，而正常路径仍是 O(1) 跳过。

3. 修正文档。 README 里"a Full-control workspace satisfies both"在非提权令牌下是误导，应补充 SeRelabelPrivilege 要求与"提权重启"这一步。这一点对 Linux/macOS 用户尤其不直观。

4. 评估降级路径。 如果唯一失败的是标签那段，是否可以在显式告警的前提下安全降级（保留受限令牌与 deny ACE、跳过 Low 标签），而不是 fail-closed 到整个沙箱不可用？对"宁可要可用性"的部署这会很有价值。

验证材料

E1 · 失败现象（任意命令，非提权启动）：

SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\DSH)

E2 · 令牌缺特权（whoami /priv，见"环境"节）——无 SeRelabelPrivilege / SeSecurityPrivilege。

E3 · 失败后 workspace ACL 残缺：

D:\DSH S-1-4-433454674-798464005:(OI)(CI)(S,DC)     ← 缺 W
       BUILTIN\Administrators:(I)(F)
       ...（无 world 的 (DC) 拒绝、无 Low 标签）

E4 · 失败被孤立在 SACL 编辑：同一非提权令牌下，仅写 DACL 成功；/setintegritylevel 报 Access is denied。

E5 · 授予特权 + 提权重启后恢复：grantWrite 通过，三段编辑齐全；纯 PowerShell cmdlet 不再需要审批即可执行；工作区外的原生程序访问改由沙箱正常拦截（表现为 [sandbox: file access denied under workspace-write mode]）。

E6 · 无自愈：以非提权方式重启 dsh 后依旧 Win32 5；即便在提权环境中成功授权过一次，若之后以非提权方式启动，仍会尝试重新 apply 并失败。

如需完整的 icacls 全量输出、whoami /all 原文或启动日志，我可以随时提供。

---

相关讨论：#423（capability ACE 永不补授）、#3434（首次授权整树遍历冻结）。本报告与二者触发条件不同，已在正文说明。