[Windows] workspace-write 沙箱在数据盘工作区完全不可用：SetNamedSecurityInfoW failed (Win32 5)

[DontSorrow-hq]

正文

标题

[Windows] workspace-write 沙箱在数据盘工作区完全不可用：SetNamedSecurityInfoW failed (Win32 5)

分类：Bug reports ｜ 标签：windows（若有）

---

正文

在数据盘（D:/E: 等根目录仅授予 Authenticated Users: Modify 的卷）上把工作区设为 workspace-write 后，该工作区内所有 shell 命令都无法执行——连 Write-Output "hello" 都跑不了。失败发生在沙箱初始化阶段，而非命令被拒：

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

Win32 5 = ERROR_ACCESS_DENIED。该路径 fail-closed，因此整个会话不可用。用户视角就是：勾了"工作区可写"，却什么都做不了，也没有任何提示告诉为什么。

根因：Modify 的掩码是 0x1301BF，按定义不含 WRITE_DAC(0x40000) 与 WRITE_OWNER(0x80000)。而自 0.1.7-alpha.1 起，沙箱为修复越界删除引入了 Low 完整性标签——标签位于 SACL，写入需要 WRITE_OWNER。源码注释已写明前提：

The directory must be owned by the caller AND grant WRITE_OWNER ... — a Full-control workspace satisfies both.

问题在于 "a Full-control workspace" 是隐含假设：数据盘工作区只有 Modify，而"目录所有者"身份只隐含 READ_CONTROL + WRITE_DAC，不足以写 SACL。C 盘用户目录给的是 (F)(FullControl)，所以那边正常——差异纯粹来自默认 ACL。

版本边界（逐版本解包确认）：0.1.5-rc.x / 0.1.6-alpha.x 用标志 4（仅 DACL），0.1.7-alpha.1 起改为 20（DACL + LABEL）。这解释了为何内置 0.1.5-rc.2 的第三方桌面端没有此问题——这是可用性回归，代价换来越界删除的修复。

临时规避（无需管理员，只要你是该目录所有者）：

icacls "<工作区路径>" /grant "<用户名>:(OI)(CI)(WO)"

(OI)(CI) 可继承，会传播到已存在的子孙目录，每个工作区一条即可。授权后实测：工作区内可写、工作区外写入被拒（隔离生效）、工作区外读取正常。

建议：不建议回退 0.1.7 的删除约束（那会重新引入越界删除）。缺口在于检测与沟通——建议加前置检查，在报错中给出 WRITE_OWNER 提示与修复命令，而非抛裸 Win32 5。

完整报告（含逐版本比对、实测输出、最小复现脚本）见附件 dsh-windows-workspace-write-writeowner-report.md。

---

Post body (English)

Title

[Windows] workspace-write sandbox is entirely unusable on data-volume workspaces: SetNamedSecurityInfoW failed (Win32 5)

Body

With a workspace on a data volume (a non-system volume whose root grants Authenticated Users: Modify), every shell command fails under the workspace-write preset — even Write-Output "hello". The failure is at sandbox bring-up, not a per-command rejection:

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

Win32 5 is ERROR_ACCESS_DENIED; the path is fail-closed, so the whole session is unusable. From the user's side: workspace-write is enabled and nothing works, with no explanation.

Root cause: Modify is 0x1301BF, which by definition excludes WRITE_DAC (0x40000) and WRITE_OWNER (0x80000). Since 0.1.7-alpha.1 the sandbox writes a Low integrity label to fix out-of-workspace deletion — the label lives in the SACL, and writing a SACL requires WRITE_OWNER. The source comment states the prerequisite:

The directory must be owned by the caller AND grant WRITE_OWNER ... — a Full-control workspace satisfies both.

"A Full-control workspace" is an implicit assumption: data-volume workspaces have only Modify, and owner-implicit rights (READ_CONTROL + WRITE_DAC) are not enough to write a SACL. C: profile directories grant (F) (FullControl), hence the discrepancy — the difference is purely the default ACL.

Version boundary (confirmed by unpacking every release): 0.1.5-rc.x / 0.1.6-alpha.x pass flag 4 (DACL only); from 0.1.7-alpha.1 it is 20 (DACL + LABEL). This explains why third-party desktops bundling 0.1.5-rc.2 are unaffected — a usability regression traded for the deletion fix.

Workaround (no elevation needed if you own the directory):

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

(OI)(CI) propagates to existing descendants, so one command per workspace suffices. Verified after granting: writes inside succeed, writes outside are denied (confinement works), reads outside still work.

Suggestion: do not revert the 0.1.7 deletion confinement (that would reintroduce out-of-workspace deletion). The gap is detection and communication — add a pre-flight check and surface the WRITE_OWNER requirement plus the fix command instead of a raw Win32 5.

Full report (per-version comparison, measured output, minimal repro script) attached as dsh-windows-workspace-write-writeowner-report.md.

[argszero]

Verified against source — and the boundary is right (re-derived, not taken on trust)

Thanks for this one: it is the first report in this family that supplies both a version boundary and a remedy narrower than the one I had been printing. Both check out, and I have adopted the second.

I re-derived the boundary per tag rather than reading it off the summary — same spirit as your unpacking, but from source:

git show <tag>:packages/sandbox/sandbox-windows-acl/src/acl.ts \
  | grep -n 'LABEL_SECURITY_INFORMATION\|buildLowLabelAcl\|setNamedSecurityInfoW'

tag	what the package's calls look like
dsh-v0.1.5-rc.2	one setNamedSecurityInfoW at :171; no LABEL_SECURITY_INFORMATION anywhere; no buildLowLabelAcl
dsh-v0.1.6-alpha.2	identical to the above
dsh-v0.1.7-alpha.1	:151 the read passes the merged flag; :169 buildLowLabelAcl; :255 the merged apply; :257 the keep-vs-apply flag choice

So flag 4 → 20 exactly as you report (LABEL_SECURITY_INFORMATION is 0x10, DACL_SECURITY_INFORMATION is 0x04). One thing worth adding to your finding: before 0.1.7-alpha.1 there was no SACL write at all — not a separate one, none. That is a stronger statement than "the flag changed", and it is what makes your inference about the third-party desktop bundling 0.1.5-rc.2 follow rather than merely be plausible.

The gate is WRITE_OWNER, and your mechanism is now cross-checked by a second report

acl.ts:368 (module docs) and the package README :122 both state the prerequisite verbatim — "The directory must be owned by the caller AND grant WRITE_OWNER … a Full-control workspace satisfies both". Your mask arithmetic is right, and "a Full-control workspace" is indeed an implicit assumption of that sentence. win32-abi.ts agrees numerically: the capability grant is GRANT_MASK = (FILE_GENERIC_WRITE | DELETE | FILE_DELETE_CHILD) & ~STANDARD_RIGHTS_WRITE = 0x110156, while Modify = 0x1301BF carries neither WRITE_DAC (0x40000) nor WRITE_OWNER (0x80000).

Independently, #7735 ran the isolation table on one machine and one unprivileged account: the label write succeeds with Full control or with Take-ownership alone, and fails with ChangePermissions, ReadPermissions or Modify alone. That settles the gate as WRITE_OWNER and nothing else, and it retires the SeSecurityPrivilege hypothesis explicitly — which is why "whoami /priv cannot show the difference, and elevation is the wrong lever" is already in the advisory text.

Your workaround is better than mine — adopted as the recommended one

I had been printing icacls "<dir>" /grant "<user>:(OI)(CI)F". Yours grants (WO) only, and it is the better answer for two reasons worth stating: WO is the right the prerequisite names, so the command grants nothing the harness did not ask for; and on a data volume "hand the whole directory over to Full control" is a bigger concession than this failure requires. Both forms are the owner case — owner-implicit rights are READ_CONTROL + WRITE_DAC, which is what covers the DACL half of the merged write — and the advisory now says so instead of leaving the reader to infer it.

Detection and communication: there is a stopgap, and 0.4.0 carries your facts

@argszero/cordis-plugin-sandbox-grant-advisor — on npm, source at https://github.com/argszero/cordis-plugin-sandbox-grant-advisor. It observes the public tools/post-execute waterfall, recognizes this exact line (and only the two ...NamedSecurityInfoW operations, so SetEntriesInAclW / LocalFree / LockFileEx failures are deliberately left alone), and attaches one durable user-role advisory per agent. It repairs nothing: no ACL is written, nothing is elevated, no mode is changed.

0.4.0 (just published) folds in your report:

• the narrow remedy first — icacls "<dir>" /grant "<user>:(OI)(CI)(WO)" — with Full control offered second, as the same line with F in place of (WO);
• the version boundary as a discriminator: "up to 0.1.6-alpha.x the backend touched the DACL only (flag 4) … 0.1.7-alpha.1 is where the mandatory label — and with it the SACL, flag 20 — arrives", so the same string on an older line belongs to a different cause space;
• your "do not revert" counsel, as the reason the downgrade it invites is refused: the label is what confines deletes to the workspace, and reverting it reintroduces the escape it closed.

npm install @argszero/cordis-plugin-sandbox-grant-advisor

It also names the second environment the identical text can describe — a directory where no ACE names the caller at all, so the inherited Authenticated Users: Modify is the whole of their access. The classifier cannot tell your shape from the mkdir-inherited one and the remedy is the same, so the advisory names both rather than guessing which it is looking at.

On evidence, honestly: what I verified is the published artifact itself — running its classifier on your exact string and printing the shipped advisory — plus the plugin's suite on every harness line its peer range admits (0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-rc.3, 0.1.6-alpha.2, 0.1.7-rc.2). The plugin was built on macOS, so it does not witness the Windows path; what is tested is the decision layer, driven by fixtures that throw the producers' exact error shapes. It does not prove icacls … :(WO) fixes any given machine — that is your measurement, and the advisory says where it stops.

Where this belongs upstream

grantWrite already computes hasExactGrant / hasExactDeny / hasExactLabel and discards which of them came back false, while the throw carries only ${label}(${path}) — that is precisely why the message cannot name the right. Your pre-flight suggestion fits there for the price of keeping one of those three names.

A detail from #7735 that argues for doing it at that site rather than above it: a failed apply rolls back atomically and can leave a stale capability ACE (0x1301FF against the current 0x110156), which makes hasExactGrant never match — so the skip path that would avoid this write entirely is unreachable on such a directory, and the write is attempted (and refused) on every provision.

On the siblings

• [Bug] Windows：沙箱给工作区根目录盖 Low 完整性标签后，目录内的 .bat/.cmd/.exe 双击弹「无法验证发布者」 #7735 is the same gate plus one further consequence of the same label (the publisher confirmation before launching an inherited-Low .bat / .cmd / .exe). That half is not observable from a tool result — nothing in the session's tool pipeline ever sees it — so it is outside what a plugin at this seam can classify. It stays with the maintainers.
• [bug] Windows workspace-write 沙箱下执行 npm 包装的 CLI 永久阻塞，并把整个 dsh web 进程拖死 #7732 is a different failure: the call never returns, so there is no tool/result and no error text at all. Nothing that classifies tool-result content can recognize it. It belongs in its own thread, with the diagnosis you already ask for there (subprocess lifecycle logging / --inspect).

[DontSorrow-hq]

回帖（discussion #7750）

回复对象：argszero 对该 discussion 的回复
定位：补上他明确声明缺失的证据 —— Windows 路径的实测

---

中文

感谢这份回复——它比我的原报告更严谨，尤其"0.1.7-alpha.1 之前根本没有任何 SACL 写入"这一点，把我的"社区版不受影响"从推测变成了推论。我原话只说"标志位从 4 变成 20"，你补的那句才是让它必然成立的那一步。
补上你说缺的那块：Windows 侧实测。

(WO) 端到端有效

你的 README 写着 "It does not prove that icacls ... :(WO) fixes a given machine — that is your measurement"。这就是那个 measurement。
环境：Windows 11 25H2（build 26200.9168）、非提权账户、工作区位于数据盘。

步骤	结果
授权前：icacls <dir> /setintegritylevel Low	Access is denied. → exit=5
icacls <dir> /grant "<user>:(OI)(CI)(WO)"	成功
授权后：同一命令	exit=0
最终标签	Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
授权后 workspace-write 会话的完整行为（逐条实测，非推断）：

• 工作区内创建 / 删除文件 → 成功
• 工作区外创建（另一数据盘目录、C:\Users\<user>）→ UnauthorizedAccessException
• 工作区外读取 → 正常（符合 workspace-write 只限制写的语义）
  即：(WO) 一条命令同时恢复可用性与保持隔离，不牺牲边界。这支持你把窄修法放在首位的判断。

版本边界：独立复现，方法不同

我不是从 git source 读的，而是解包已发布的 npm tarball（@deepseek-ai/dsh-sandbox-windows-acl，逐版本），统计 FILE_DELETE_CHILD、label 相关符号与 setNamedSecurityInfoW 的标志值：

版本	FILE_DELETE_CHILD	label 逻辑	setNamedSecurityInfoW 标志
0.1.5-rc.1 / rc.2 / rc.3	0	0	4
0.1.6-alpha.1 / alpha.2	0	0	4
0.1.7-alpha.1	有	有	20
0.1.7-alpha.2 / rc.1	有	有	20
差别在于：这是在用户实际安装的产物上验证，而非仓库源码。你的 git show 与它互为交叉验证 —— 两条独立路径得到同一边界。

一个反向结果：本机没有陈旧 ACE

#7735 描述的 0x1301FF 残留（使 hasExactGrant 永不命中、每次 provision 都要重走完整 apply 并再次要求 WRITE_OWNER）在本机没有出现。扫描 16 个曾作为工作区的目录：

• 8 个：现行掩码 0x110156
• 8 个：未检出能力 ACE（推测为已授 WO，但该目录尚未在 0.1.7 下成功 provision）
• 0 个：陈旧 0x1301FF
  所以陈旧状态并非必然结果 —— 失败停在 apply 的哪个阶段可能才是决定因素。这对"陈旧 ACE 使跳过路径不可达"是一条边界数据点，不是反驳。

0.1.7-rc.2 的状态

0.1.7-rc.2 已发布（Windows x64 安装包 274.9 MB，数字签名 Valid），该问题仍未修复 —— 更新日志中无相关条目，本机升级后实测现象不变。
但有一点对已踩坑的用户是好消息：升级不丢授权。WO ACE 与 Low 标签都是文件系统状态，不在 DSH 配置里，因此升级（乃至重装应用）后依然存在 —— 我在升级到 rc.2 后复测确认了工作区内可写、工作区外被拒。对已修复的机器而言这是一次性代价。

---

English

Thanks for this — it is more rigorous than my original report, particularly the point that before 0.1.7-alpha.1 there was no SACL write at all. That is the step that turns my "third-party desktops bundling 0.1.5-rc.2 are unaffected" from plausible into following; my own phrasing only said "the flag changed from 4 to 20".
Here is the piece your README says it lacks — the Windows measurement.

(WO) verified end to end

Your README states: "It does not prove that icacls ... :(WO) fixes a given machine — that is your measurement." This is that measurement.
Windows 11 25H2 (build 26200.9168), unprivileged account, workspace on a data volume:

Step	Result
Before grant: icacls <dir> /setintegritylevel Low	Access is denied. → exit=5
icacls <dir> /grant "<user>:(OI)(CI)(WO)"	succeeded
After grant: same command	exit=0
Resulting label	Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
Full behaviour of the workspace-write session afterwards (measured, not inferred):

• create / delete inside the workspace → succeeds
• create outside (another data-volume directory, C:\Users\<user>) → UnauthorizedAccessException
• read outside → works (consistent with workspace-write confining writes only)
  So one (WO) command restores usability and keeps confinement intact — it does not trade the boundary away. That supports putting the narrow remedy first.

Version boundary — independently reproduced by a different method

I did not read it from git source; I unpacked the published npm tarballs (@deepseek-ai/dsh-sandbox-windows-acl, every version) and counted FILE_DELETE_CHILD, the label symbols, and the setNamedSecurityInfoW flag value:

version	FILE_DELETE_CHILD	label logic	setNamedSecurityInfoW flag
0.1.5-rc.1 / rc.2 / rc.3	0	0	4
0.1.6-alpha.1 / alpha.2	0	0	4
0.1.7-alpha.1	present	present	20
0.1.7-alpha.2 / rc.1	present	present	20
The difference is that this is verified on the artifact users actually install rather than the repository source. Your git show and this cross-check each other — two independent paths to the same boundary.

A negative result: no stale ACE on this machine

The 0x1301FF residue described in #7735 — which makes hasExactGrant never match and forces every provision back through the full apply, demanding WRITE_OWNER each time — did not occur here. Across 16 directories that have served as workspaces:

• 8: current mask 0x110156
• 8: no capability ACE detected (presumably granted WO but not yet successfully provisioned under 0.1.7)
• 0: stale 0x1301FF
  So the stale state is not inevitable; where a failed apply stops may be what decides it. That is a boundary data point for the "stale ACE makes the skip path unreachable" inference, not a counterexample.

Status of 0.1.7-rc.2

0.1.7-rc.2 has shipped (Windows x64 installer, 274.9 MB, signature Valid) and does not fix this — nothing in its changelog addresses it, and the behaviour is unchanged here after upgrading.
One piece of good news for anyone already hit by it: upgrading does not lose the grant. The WO ACE and the Low label are filesystem state, not DSH configuration, so they survive an upgrade (and even a reinstall) — re-verified after moving to rc.2 (writes inside succeed, writes outside denied). For a repaired machine this is a one-time cost.