[Bug/UX] Windows：工作区目录所有者为 BUILTIN\Administrators 时，workspace-write 下所有命令直接失败（grantWrite / SetNamedSecurityInfoW Win32 5）

[zqh260619]

我在vibe我的预设的时候ds向我报告了如下的问题：

环境

• DSH：0.1.7-rc.1（npm 全局安装，profile web）
• 平台：Windows 11 25H2(10.0.26200.9457,x64)，以非提升权限运行的普通管理员账户（UAC 过滤令牌，Medium 完整性）
• 会话权限预设：workspace-write（approval: ask）
• 工作区：D:\ZQH260619\repos\DshAgentPresetForPlugin —— 目录所有者是 BUILTIN\Administrators，对当前用户只有继承来的 Modify

现象

workspace-write 下任何 shell 命令都不执行，直接失败：

SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\ZQH260619\repos\DshAgentPresetForPlugin)

没有命令输出、没有退出码 —— 命令从未被 spawn，因此也无法用“先跑个 echo 看看”绕过。
对照：同一工作区切到 danger-full-access 一切正常；切到 read-only 也正常（只读模式不授予可写根，因此不会走到这个调用）。

复现

1. 准备一个「所有者为 BUILTIN\Administrators、且当前用户只继承到 Modify」的目录作为工作区（例如由提升权限的安装程序/解压工具创建，或位于管理员所有的父目录之下）；
2. 以非提升权限启动 DSH，用 workspace-write 开会话；
3. 执行任意命令（pwsh -Command "echo hi"）。

诊断

> whoami /groups
BUILTIN\Administrators    Alias    S-1-5-32-544    Group used for deny only
Mandatory Label\Medium Mandatory Level              S-1-16-8192
> whoami /priv
（无 SeTakeOwnership / SeRestore / SeBackup）

> (Get-Acl 'D:\ZQH260619\repos\DshAgentPresetForPlugin').Owner
BUILTIN\Administrators
# 对该令牌实际生效的条目仅：
#   NT AUTHORITY\Authenticated Users:(I)(M)
#   BUILTIN\Users:(I)(RX)
#   （Administrators:(I)(F) 对该令牌是 deny-only，不可用）

另外该目录上残留一条非继承的 capability ACE S-1-4-…:(W,D,DC)，说明历史上曾成功授权过——即该目录并非永远不可授权，只是当前令牌不具备条件。

结论：合并应用 capability ACE + 删除拒绝 + Low 标签需要 WRITE_DAC（写 SACL 标签还需要 WRITE_OWNER）。当前令牌既不是所有者（所有者是对它 deny-only 的 Administrators 组），也没有 SeTakeOwnership，因此 SetNamedSecurityInfoW 返回 ERROR_ACCESS_DENIED (5)。

我理解这正是 sandbox-windows-acl README「已知限制」里写的 fail-closed 前提（“被授权目录必须由调用者拥有并授予 WRITE_OWNER … DACL 只授予 Modify 的目录现在会大声失败”）。本 issue 不是要求放弃 fail-closed，而是希望改善这个前提在 Windows 上的可达性与可诊断性：

建议

1. 预检 + 可操作错误：在需要授予时（或工作区连接时）先检测该前提，若“所有者非当前用户 / 无 WRITE_DAC·WRITE_OWNER”，直接给出修复命令，例如：
   • 提权执行 icacls "D:\ZQH260619\repos\DshAgentPresetForPlugin" /grant "PC-20260130TXZG\Administrator:(OI)(CI)F"，或 icacls "D:\ZQH260619\repos\DshAgentPresetForPlugin" /setowner "PC-20260130TXZG\Administrator"
   • 或改用用户自有目录（如 %USERPROFILE%\repos\...）
     现状是只抛 SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\ZQH260619\repos\DshAgentPresetForPlugin)，用户完全不知道下一步做什么。
2. 文档：把这条前置要求补进面向用户的 Windows 排障文档（目前只在包 README 的「已知限制」中），并说明应急通道（Web 用户终端不受 Agent 沙箱限制）。
3. 是否可放宽：Low 标签位于 SACL，是 WRITE_OWNER 依赖的来源。能否在无法写 SACL 时提供明确的降级/opt-out（例如只授予 capability ACE 而不打标签，并在界面标注隔离强度下降），或至少在错误里区分“DACL 写入失败 / 标签写入失败”两个分支？
4. 如果这种环境确实不受支持，也请在错误文本里直说「不支持：工作区所有者为其他账户或组，请改所有者或更换目录」，以便他人搜索到。

版本核对

• 0.1.7-rc.1：复现；
• 0.1.7-rc.2：@deepseek-ai/dsh-sandbox-windows-acl 与 rc.1 逐字节相同（4 个文件大小一致；含该调用点的 lib/types-DxezulnA.js 均为 61058 B、SHA-256 E6014E93…7E0098），故 rc.2 未修复。

相关但不同的讨论（供去重）

#401 / #423（子目录 ACE 永不补授）、#2287（临时目录 ACL 重施后失去创建者权限）、#469 / #3430（workspace-write 冻结）、#3919（Google Drive VFS，Win32 87）、#4290（mkdir 0700 空 DACL）。
本问题是工作区根目录本身不可被当前令牌修改 ACL，与上述成因不同，请勿按重复关闭。

临时绕过

提权 icacls 改所有者/补完全控制；或把工作区移到用户自有目录；或临时把该会话权限设为 danger-full-access。

---

English summary

On Windows, when the workspace directory is owned by BUILTIN\Administrators while DSH runs from a UAC-filtered (Medium integrity) token, every workspace-write command fails before spawning:

SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\ZQH260619\repos\DshAgentPresetForPlugin)

The token has only inherited Modify on that directory (the Administrators ACE is deny-only for it, and there is no SeTakeOwnership), so it cannot write the DACL/SACL that the capability grant requires — a documented fail-closed precondition in the sandbox-windows-acl README, but one with a very common Windows trigger and a non-actionable error message. Requested: a preflight check with the exact icacls/setowner remediation (or a documented "unsupported layout" error), user-facing troubleshooting docs, and possibly a labeled degradation path when the SACL label cannot be written. read-only is unaffected (no writable root, no grant). Same failure in 0.1.7-rc.2: the sandbox package is byte-identical to rc.1.

[CNyaotian-Lunar]

同一个缺陷，另一半入口：非系统盘（不需要"所有者是 Administrators"）/ Same defect, the other half of the trigger: non-system drive

我们独立撞上了同一个 bug（SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)），事后才发现你已经报过这里。补一条，把另一半触发条件和一份可直接复现的实验放上来，希望能帮这份报告把适用范围说全。

We hit the same bug independently (SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>), workspace-write unusable) and only later found your report. Adding the other half of the trigger plus a paste-ready reproduction so this report covers the full scope.

我们这边的前提和你的不同 / Our precondition differs from yours

你的场景是「目录所有者是 BUILTIN\Administrators」（提权工具/安装程序创建的目录）。我们这边所有者就是当前用户，照样稳定失败 —— 因为真正的门槛不是"谁是所有者"，而是写 SACL 的 mandatory integrity label 需要 WRITE_OWNER，而：

Your case is "the directory is owned by BUILTIN\Administrators" (created by an elevated tool/installer). Ours is owned by the current user and still fails deterministically — because the real gate is not who owns it but that writing the SACL's mandatory integrity label requires WRITE_OWNER, and:

• 目录属主只隐含 READ_CONTROL + WRITE_DAC，不含 WRITE_OWNER；
  A directory's owner implies only READ_CONTROL + WRITE_DAC — not WRITE_OWNER;
• 非系统盘的默认 ACL 是 Authenticated Users: Modify + Users: ReadAndExecute（继承），不含创建者的 FullControl；
  a non-system drive's default ACL is Authenticated Users: Modify + Users: ReadAndExecute (inherited), with no FullControl for the creator;
• 于是调用者拿不到 WRITE_OWNER ⇒ ERROR_ACCESS_DENIED (5)。
  so the caller never has WRITE_OWNER ⇒ ERROR_ACCESS_DENIED (5).

⇒ 结论：只要工作区在 D: / E: / F: 这类非系统盘上，就必然中招，不需要"所有者是 Administrators"这个额外前提。（对比：C:\Users\<user>\… 下新建的目录天生继承调用者 FullControl，所以官方常规测试环境看起来一切正常 —— 这大概也是这个坑长期没被暴露的原因。）

⇒ Net: any workspace on a non-system volume (D: / E: / F:) hits it, with no need for the "owner is Administrators" precondition. (For contrast, directories created under C:\Users\<user>\… inherit the caller's FullControl, which is very likely why the common dev setup never exposes this.)

最小复现（不需要装 DSH）/ Minimal reproduction (no DSH needed)

用系统自带 icacls 就能复现同一条权限路径 / The built-in icacls reproduces the exact privilege path:

New-Item -ItemType Directory -Force F:\probe | Out-Null
(Get-Acl F:\probe).Access | Where-Object IdentityReference -match $env:USERNAME   # → 无输出 / no output

icacls F:\probe /setintegritylevel Low
#   → Access is denied. (exit 5)        ← 与 DSH 报的 Win32 5 同源 / same source as DSH's Win32 5

icacls F:\probe /grant "$env:USERNAME:(OI)(CI)F"     # 补上含 WRITE_OWNER 的完全控制 / grant FullControl incl. WRITE_OWNER
icacls F:\probe /setintegritylevel Low
#   → Successfully processed 1 files. (exit 0)

（在 C:\Users\<user>\ 下重复前两步 —— 天生成功。）
(Repeat the first two steps under C:\Users\<user>\ — they succeed out of the box.)

立刻可用的修复（用户侧）/ Immediate workaround (user side)

icacls <workspace> /grant "<user>:(OI)(CI)F"     # 全树传播约 3~4 分钟 / propagates across the tree, ~3–4 min
# 回滚 / rollback：
icacls <workspace> /remove:g "<user>"

授权后 workspace-write 立即恢复正常（沙箱能正常建受限令牌并 spawn）。等价替代：icacls <workspace> /setowner "<user>"，或把工作区挪到 %USERPROFILE% 之下。

After the grant, workspace-write works again immediately. Equivalents: icacls <workspace> /setowner "<user>", or just move the workspace under %USERPROFILE%.

给上游的两条（与你那条的建议同向，但更强调"降级"）/ Two suggestions (same direction as yours, with more emphasis on degradation)

1. 预检 + 可粘贴的修复命令：init() 之前探测 WRITE_OWNER/写 SACL 能力，失败时直接把上面那条 icacls 打出来，而不是只抛 Win32 5；
   Pre-flight + paste-ready fix: probe WRITE_OWNER/SACL capability before init() and print the icacls line above on failure instead of a bare Win32 5;
2. 写 SACL 失败时应可降级，而不是让整条命令路径全死：例如只施加 capability ACE、跳过 Low 标签，并在结果里明确标注"隔离强度下降"（甚至把错误文本明确区分「DACL 写入失败」与「标签写入失败」）。
   A SACL failure should degrade, not kill the whole command path: e.g. apply only the capability ACE, skip the Low label, and clearly report reduced isolation strength (or at least distinguish "DACL write failed" from "label write failed" in the error).

—— 我们那边写成了一份更细的报告（含 icacls 四步复现、NTFS 前提核对、以及"为什么常规环境不会暴露"）：#7804。你这条可以先看，两条互为补充。

—— We wrote this up in more detail (the four-step icacls repro, NTFS preconditions, and why normal environments never expose it): #7804. Either report stands on its own; together they cover both triggers.

---

本评论由 DSH agent 整理、经人工复核后提交；上面的命令在 Windows 11 + NTFS 非系统盘上可直接复现。
Written up by a DSH agent, reviewed by a human before posting; the commands above reproduce directly on Windows 11 + an NTFS non-system volume.

[argszero]

A plugin-layer stopgap for this exact shape — and a correction to what it printed before today

I maintain @argszero/cordis-plugin-sandbox-grant-advisor (npm / public repo). It hooks the public tools/post-execute waterfall, recognizes this one signature, and attaches a single user-role advisory to the failing result — the error text names neither the cause nor a remedy, so the diagnosis is delivered in-band instead. 0.5.0, published today, is the first release that handles your environment specifically.

Why 0.5.0 exists: the previous version's one-liner cannot run here

0.4.0 printed a single unconditional fix:

icacls "<dir>" /grant "<user>:(OI)(CI)(WO)"

That line is correct where the caller owns the directory — the owner's implicit rights include WRITE_DAC, so icacls /grant can itself succeed, and WRITE_OWNER is the only missing right. In your environment it cannot run at all: changing a DACL needs WRITE_DAC, and — as you documented — the token holds neither ownership (owner BUILTIN\Administrators, deny only for this token) nor any ACE granting it, nor SeTakeOwnership. icacls /grant is refused with Access is denied for the very command that would repair the sandbox. And because the DACL and the mandatory label go out as one SetNamedSecurityInfoW, granting (WO) alone would not have been enough either: that write needs WRITE_DAC and WRITE_OWNER together.

So 0.5.0 forks the remedy on a check the user runs — (Get-Acl "<dir>").Owner — and gives each branch the command that works there:

• you own it — the unelevated line above (the [Windows] workspace-write 沙箱在数据盘工作区完全不可用：SetNamedSecurityInfoW failed (Win32 5) #7750 reporter verified this form working), or the same line with F;
• you do not own it — run the grant from an elevated prompt: icacls "<dir>" /grant "<your-account>:(OI)(CI)F"; or take ownership first, also elevated (it wants SeTakeOwnership), after which the unelevated (WO) line applies; or sidestep the ACL by creating the workspace under %USERPROFILE%.

It also states plainly that takeown is not the fix on its own: ownership's implicit rights are READ_CONTROL + WRITE_DAC — the DACL half, never WRITE_OWNER.

On your four suggestions

1. Pre-flight, with an actionable error — that part is still upstream's to do: a plugin speaks after the failure, it cannot pre-empt it. What it can deliver is the actionable half — the paste-ready command for the right branch, inside the same result the model and the user are looking at.
2. Documentation — the package README now carries the two-branch remedy, and the advisory quotes the backend's own prerequisite (granted directories must be caller-owned and grant WRITE_OWNER) next to the error, because at failure time that README is not what the user sees.
3. Optional degradation (apply the ACE, skip the label) — deliberately not offered, and I would push back on it as a default: the runner lowers the sandboxed token to Low integrity (restrictTokenIntegrity, sandbox-windows-acl/src/index.ts:289), and a Low-integrity process cannot write a Medium-labelled directory (no-write-up). Skipping the label on ERROR_ACCESS_DENIED would let the grant "succeed" while every actual write inside the sandbox still failed — a loud error traded for a silently broken one. (kittimzhe argues this at length on workspace-write sandbox fails entirely on Windows when the workspace grants no WRITE_OWNER (SetNamedSecurityInfoW error 5) #7816.) The diagnostic half of your suggestion is compatible with staying fail-closed and worth having: distinguishing "DACL write failed" from "label write failed".
4. Say it plainly when the environment is unsupported — agreed in spirit, and the advisory now names the not-owned case explicitly rather than implying it is a one-liner.

Scope, honestly

This is a stopgap, not a fix: the plugin never edits an ACL and never elevates, and the upstream gap — a failure that names neither the missing right nor a remedy, under a precondition that is not pre-flighted — remains open in packages/sandbox/sandbox-windows-acl/src/acl.ts. Verified at master 477b4f4205: mergeAndApply still applies DACL and label in one SetNamedSecurityInfoW, and the failure text is still the bare Win32 code.

One thing you were right about that needs no fix: read-only works because it never reaches this path — with no writable root there is no write SID, so grantWrite is never called and nothing writes a label.

• install: npm i @argszero/cordis-plugin-sandbox-grant-advisor

[CNyaotian-Lunar]

先道谢、也道歉，然后是两处更正与一处场景澄清

谢谢跟进，也为我们报告里两条站不住的建议道歉。我们复核了源码，你的两处更正都对：① read-only 从不写安全描述符（runner.js:144 令 writableDirs 为空、构造函数禁止其携带 write SID）⇒ 它不可能触发该失败，我们原先「read-only 也应纳入预检」的建议撤回；② restrictTokenIntegrity 在 init() 里无条件执行，跳过 Low 标签会让授权「成功」而沙箱内写入全被 no-write-up 拒绝 ⇒ 不作默认降级是对的，我们只保留「区分 DACL / 标签写入失败」这半条。

另外澄清一处对我们那条补充的归属：我们说的是非系统盘 + 目录所有者就是调用者本人（不是本贴的 BUILTIN\Administrators）。在该格子里，非提权的 icacls <dir> /grant "<user>:(OI)(CI)(WO)" 即最小充分修复 —— 我们刚在同一台受影响的机器上实测：/setintegritylevel Low 由 exit 5 → exit 0。我们报告里把 /setowner 当等价替代那句也是错的，已在 #7804 更正。

English version

Thanks, apologies, two corrections, and one scope clarification

Thanks for following up — and apologies for the two suggestions in our report that do not hold. We re-checked the source: both of your corrections hold. (1) read-only never writes a security descriptor (runner.js:144 leaves writableDirs empty and the constructor forbids a write SID) ⇒ it cannot hit this failure, so we withdraw the "read-only should share the pre-flight" suggestion. (2) restrictTokenIntegrity runs unconditionally in init(), so skipping the Low label would let the grant "succeed" while every write inside the sandbox is refused by no-write-up ⇒ keeping it fail-closed is right; we keep only the "distinguish DACL vs label write failure" half.

One clarification on the scope of our addition: we mean non-system drive + the caller is the directory owner (not this thread's BUILTIN\Administrators). In that cell the unelevated icacls <dir> /grant "<user>:(OI)(CI)(WO)" is the minimal sufficient fix — just measured on the same affected machine: /setintegritylevel Low goes exit 5 → exit 0. Our report's /setowner line was wrong too and is corrected on #7804.