[Bug Report] Windows: workspace ACL with Modify-only (no WRITE_OWNER) makes the ACL sandbox fail at init, disabling all shell tools

[cdh665]

Summary

On Windows, if the workspace directory's DACL grants the user only Modify
(no WRITE_OWNER), the ACL sandbox fails at initialization and every shell
tool call dies - not just a denied operation. The error message gives no hint of
the requirement.

The package README documents the requirement, but claims FullControl is "the
normal workspace case". On a normal data volume that assumption is wrong, so this
is a very easy trap to fall into right after upgrading.

Environment

• Windows, account <user> - running with a non-elevated token
• @deepseek-ai/dsh@0.1.7-rc.1 (installed from npm, next tag), dsh web
• Workspace: E:\<workspace> - an ordinary folder on a data volume
• PowerShell execution policy RemoteSigned; session file policy workspace-write
• Was on 0.1.5-rc.3 before the upgrade

Reproduction

1. Create a folder on a data volume (e.g. E:\<workspace>). It inherits from the
   drive root:

   E:\<workspace> BUILTIN\Administrators:(I)(F)
                  NT AUTHORITY\SYSTEM:(I)(F)
                  NT AUTHORITY\Authenticated Users:(I)(M)   <-- Modify only
                  BUILTIN\Users:(I)(RX)
   

   Note: no explicit ACE for the user account, and Modify does not include
   WRITE_OWNER.

2. Start dsh web without elevation and connect the workspace.

3. Ask the agent to run any shell command.

Current behaviour

Every tool call fails immediately, before the command runs:

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(E:\<workspace>)

Win32 5 = ERROR_ACCESS_DENIED. Because the failure is in sandbox init, all
shell commands are unavailable (even netstat, icacls).

On 0.1.5-rc.3 the same setup worked, because the confinement was silently
skipped. So this is a regression introduced by the switch to fail-closed.

Root cause

@deepseek-ai/dsh-sandbox-windows-acl applies the DACL grant and the low
integrity label in a single SetNamedSecurityInfoW call. Because the label
lives in the SACL, the call needs both:

• WRITE_DAC (or ownership), and
• WRITE_OWNER, which a Modify-only DACL does not grant.

Independently reproduced outside DSH: writing the DACL on E:\<workspace> from a
non-elevated PowerShell fails with the equivalent
UnauthorizedAccessException: Attempted to perform an unauthorized operation.
After granting the user explicit FullControl, everything works without elevation.

Things that do NOT fix it

• takeown /F E:\<workspace> /R /D Y - makes the user the owner, but the owner's
  implicit rights cover only READ_CONTROL + WRITE_DAC, not WRITE_OWNER.
• icacls E:\<workspace> /reset /T /C - restores inheritance, which restores the
  Modify-only ACE. Still fails.

Workaround that works

icacls "E:\<workspace>" /grant "<user>:(OI)(CI)F"

(Or run dsh from an elevated terminal.)

Expected behaviour

Either it should work on a stock workspace, or the failure should tell the user
exactly what to do.

Proposed improvements

1. Preflight the workspace DACL at startup. Detect the missing
   WRITE_OWNER before the first tool call and either (a) offer to apply the
   FullControl grant with consent, or (b) fail with an actionable message that
   includes the exact icacls command.
2. Surface the requirement in user-facing docs. The constraint is currently
   only in the package README's "Known Limitations", which nobody reads at the
   moment the failure happens. A troubleshooting page for the Windows sandbox
   would help.
3. Fix the README's assumption. "A directory whose DACL grants only Modify
   now fails the grant loudly ... (a Full-control directory, the normal
   workspace case, has it)". On a data volume, Authenticated Users:(M)
   inherited from the drive root is the normal case, especially for non-admin
   accounts with no explicit ACE of their own. The doc reads as if this were an
   edge case; in practice it is the default.

Note

Verified on master that this limitation is still documented unchanged, and
pushed_at still equals the 0.1.7-rc.1 release time, so I'm reporting it as
still open rather than a duplicate of a fix in flight.

概要

Windows 上，如果工作区目录的 DACL 只给用户 Modify（不含 WRITE_OWNER），
ACL 沙箱会在初始化阶段失败，导致所有 shell 工具不可用——不是某次操作被拒。
而报错信息完全没有提示这个前提条件。

该约束写在包的 README 里，但其中声称 FullControl 是"工作区的常态"。在普通数据盘上
这个假设是错的，所以升级后极容易踩到。

环境

• Windows，账户 <user>，以非提权令牌运行
• @deepseek-ai/dsh@0.1.7-rc.1（npm next 标签安装），dsh web
• 工作区 E:\<workspace>，数据盘上的普通文件夹
• 执行策略 RemoteSigned，会话文件策略 workspace-write
• 升级前为 0.1.5-rc.3

复现

1. 在数据盘新建文件夹（如 E:\<workspace>），它从盘根继承：

   E:\<workspace> BUILTIN\Administrators:(I)(F)
                  NT AUTHORITY\SYSTEM:(I)(F)
                  NT AUTHORITY\Authenticated Users:(I)(M)   <-- 仅 Modify
                  BUILTIN\Users:(I)(RX)
   

   注意：没有针对用户账户的显式 ACE，且 Modify 不含 WRITE_OWNER。

2. 不提权启动 dsh web 并连接该工作区。

3. 让 agent 执行任意 shell 命令。

实际行为

每次工具调用都在命令真正执行前就失败：

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(E:\<workspace>)

Win32 5 = ERROR_ACCESS_DENIED。由于失败发生在沙箱初始化，所有 shell 命令
都不可用（连 netstat、icacls 都跑不了）。

在 0.1.5-rc.3 上同样的配置是正常的——因为当时沙箱会静默跳过限制。因此这是切换
到 fail-closed 之后引入的回归。

根因

@deepseek-ai/dsh-sandbox-windows-acl 把 DACL 授权和低完整性标签放在同一次
SetNamedSecurityInfoW 调用里提交。因为标签位于 SACL，这次调用同时需要：

• WRITE_DAC（或属主身份），以及
• WRITE_OWNER —— 而仅有 Modify 的 DACL 不提供它。

在 DSH 之外独立复现：非提权 PowerShell 向 E:\<workspace> 写入 DACL，报等价的
UnauthorizedAccessException: Attempted to perform an unauthorized operation.。
给用户显式授予 FullControl 后，无需提权即可正常工作。

试过但无效的修法

• takeown /F E:\<workspace> /R /D Y —— 用户成了属主，但属主只隐含
  READ_CONTROL + WRITE_DAC，不含 WRITE_OWNER。
• icacls E:\<workspace> /reset /T /C —— 恢复继承，也就恢复了"仅 Modify"的 ACE，依旧失败。

有效的绕过

icacls "E:\<workspace>" /grant "<user>:(OI)(CI)F"

（或在管理员终端里启动 dsh。）

期望行为

要么在普通工作区上直接可用，要么报错明确告诉用户该怎么做。

改进建议

1. 启动时预检工作区 DACL：在首次工具调用前发现缺失的 WRITE_OWNER，要么（a）
   征得同意后自动补上 FullControl 授权，要么（b）给出可执行的报错，直接附上那条
   icacls 命令。
2. 把该前提写进面向用户的文档：目前它只出现在包 README 的"已知限制"里，而故障
   发生时没人会去翻那里。建议为 Windows 沙箱加一篇排障文档。
3. 修正 README 的假设："(a Full-control directory, the normal workspace
   case, has it)" —— 在数据盘上，从盘根继承来的 Authenticated Users:(M) 才是
   常态，尤其是没有自身显式 ACE 的非管理员账户。文档读起来像是边缘情形，实际是默认
   情形。

备注

已在 master 上确认该限制说明未变，且 pushed_at 仍等于 0.1.7-rc.1 的发布时间，
因此按"尚未修复"报告，而非重复报告在途修复。

[argszero]

Your root cause holds up on the source side, and the failure you are hitting already has a shipped, plugin-shaped answer.

The merged write is real. @deepseek-ai/dsh-sandbox-windows-acl submits the DACL grant and the low-integrity label in a single SetNamedSecurityInfoW: the apply branch carries both the merged ACL and { kind: 'apply', acl: label } into one descriptor, which is why the label's presence in the SACL makes the call need WRITE_OWNER on top of WRITE_DAC. An inherited Authenticated Users:(M) grants neither. Your out-of-DSH reproduction is the cleanest possible statement of that.

The missing prerequisite already has a carrier. Because the requirement is documented but the error line does not name it, we published @argszero/cordis-plugin-sandbox-grant-advisor@0.2.0 (source: https://github.com/argszero/cordis-plugin-sandbox-grant-advisor). It mounts into any dsh profile and recognises exactly this line:

SetNamedSecurityInfoW failed (Win32 5): grantWrite(<dir>)

On a match it attaches an advisory to the failing tool result — your suggestion 1(b), without waiting for a core change:

Confirm the cause (unelevated) — `icacls` is a normal user command:
  icacls "<dir>"
Look for an ACE that names YOUR OWN account (run `whoami` if unsure) with (F) / Full control.
If the strongest entry naming you is (M) / Modify, that is this failure.

Fix it (unelevated, one line) and then run the command again:
  PowerShell: icacls "<dir>" /grant "$env:USERNAME:(OI)(CI)F"
  cmd:        icacls "<dir>" /grant "%USERNAME%:(OI)(CI)F"

That is the same one-liner your Workaround that works section verified, plus a discriminator: it has the reader check their own SID's ACE for (F) before applying the fix, so a fix that does not work still teaches something instead of being repeated. The advisory also states that this is a directory-ACL fact and not a token privilege (whoami /priv will not show it; SeSecurityPrivilege is the wrong lever), and that file read/write tools keep working while sandboxed command execution is blocked — i.e. it is written for your "init fails, so every command dies" framing rather than for one denied operation. The same package also recognises a second family, the persistent PTY that cannot start under a confining sandbox.

Honest boundaries, since your suggestion list is about where the fix belongs. The plugin is advice-only: it neither edits ACLs nor elevates — the icacls line stays yours to run, and it never retries the command. It fires after the failure, alongside the result, so it is your 1(b) and not your 1(a): a startup preflight would have to read the workspace DACL from inside the very process whose sandbox cannot provision, and it cannot spawn a helper to do it either, because command execution is what is broken. Your #2 and #3 are core-facing (docs and the README's "the normal workspace case" assumption, which your data-volume ACE listing shows is wrong in practice) — there is nothing a plugin can do about those.

What this report adds that our advisory does not yet carry — the two things you tried that do not fix it. takeown /F <dir> /R /D Y makes you the owner, but ownership's implicit rights are READ_CONTROL + WRITE_DAC, never WRITE_OWNER. icacls <dir> /reset /T /C restores inheritance, which restores the Modify-only ACE. Both look like the right move, which is exactly the traffic an advisory should pre-empt; we will add them in a follow-up release of the plugin.

[cdh665]

Thanks - that lines up with what we found on the source side, and the merged-write
explanation matches the code path we read in
packages/sandbox/sandbox-windows-acl (hasExactGrant / hasExactDeny /
hasExactLabel all feeding one SetNamedSecurityInfoW).

Notes from the reporter's side:

1. Verified on 0.1.7-rc.1, non-elevated launch, workspace on a data volume whose
   inherited ACE is Authenticated Users:(I)(M). The explicit
   icacls "<dir>" /grant "<user>:(OI)(CI)F" resolved it, and after that:

   • the confined shell works again;
   • out-of-workspace writes are still denied, so the sandbox is still enforcing;
   • the confined token reports IsInRole(Administrator) == False, so the fix did
     not quietly turn into an elevation workaround.

2. One correction for the advisory text: the PowerShell form will not parse as
   written. "$env:USERNAME:(OI)(CI)F" makes PowerShell read USERNAME: as a
   scoped-variable / drive-qualified name and fail. It needs braces:
   icacls "<dir>" /grant "${env:USERNAME}:(OI)(CI)F". The cmd form
   (%USERNAME%:(OI)(CI)F) is fine. We used the full host\user string, which
   also works.

3. The two dead ends you plan to add are exactly the right ones, and the ownership
   subtlety is the part that costs the most time: takeown /F <dir> /R /D Y makes
   you the owner, but ownership's implicit rights are only READ_CONTROL +
   WRITE_DAC; and icacls <dir> /reset /T /C restores the very inheritance that
   carries the Modify-only ACE. Both look like the correct move, and neither helps.

4. On the two core-facing items: they remain open upstream. A troubleshooting page
   for the Windows sandbox, and the README line calling a Full-control directory
   "the normal workspace case" - which a data-volume icacls listing shows is not
   the normal case in practice. Worth keeping the thread open for those, rather
   than treating this as resolved.

The plugin is a good stopgap for 1(b). Thanks for turning this into something a
user sees at the moment of failure, instead of after a 50-minute detour.

[argszero]

Follow-up: the two remedies you tried are now named in the plugin, with the reason each fails.

Released @argszero/cordis-plugin-sandbox-grant-advisor@0.3.0 (commit c1f9850). The advisory now carries this section after the fix commands:

What will NOT fix it — both look like the right move, and both were tried and reported:
  takeown /F "<dir>" /R /D Y
    makes you the owner, but ownership's implicit rights are READ_CONTROL and WRITE_DAC only.
    The owner does not implicitly hold WRITE_OWNER, which is the right this call needs.
  icacls "<dir>" /reset /T /C
    restores inheritance, and inheritance is what supplied the Modify-only ACE above.

Your "Things that do NOT fix it" section is the reason this is worth its lines: both commands are the natural reach for a Windows permission problem, both appear to do the right thing, and the failure of each is only explicable from the two facts above — so a reader who already tried them learns why, and one who has not is spared the attempt. It is also why the section is emitted only for the ERROR_ACCESS_DENIED class: on a GetNamedSecurityInfoW failure the missing right is READ_CONTROL, which taking ownership does carry, so calling takeown a non-fix there would be a confidently wrong statement in the other direction. Both arms are pinned by tests, and an injected mutation that widens the gate to the wrong class is caught.

Your report is now in the advisory's upstream list (#7538 / #7622 / #7646 / #7720), and the module docs record what it sharpened: because the grant is materialized at sandbox initialization, the failure takes every shell tool with it, not one operation.

Unchanged boundaries, so the credit lands where it belongs: this is advice delivered alongside the failing result, not a startup preflight — your 1(a) still needs a change at the provisioning site. Your 2 and 3 (the missing troubleshooting page, and the README calling Full-control "the normal workspace case" when an inherited Authenticated Users:(M) is) are core/docs-facing, and nothing in a plugin can fix them.

[cdh665]

Thanks for folding both dead ends in, and for scoping the new section to the
ERROR_ACCESS_DENIED class only - that distinction (READ_CONTROL being a right
ownership does carry) is exactly the kind of thing a blanket warning would have
gotten wrong. Confirmed on our side that the facts you quote still match what we
measured: non-elevated launch, inherited Authenticated Users:(M), the explicit
FullControl grant fixing it, and out-of-workspace writes still denied afterwards.

Nothing further needed from us. Leaving the two upstream items (the troubleshooting
page and the README's "normal workspace case" wording) to the maintainers - I'll
leave the report open for those.