[Bug][Windows][FAT/exFAT] 两项静默失效：ACL 沙箱在不存储 DACL 的卷上"授权成功但零效果"（与出厂 README 的 "fails loudly" 相反）；版本令牌在 2 秒时间戳卷上漏检外部改动

[wannagoxuf]

摘要（EN）On a workspace hosted on a FAT-class volume (exFAT here), two Windows-specific mechanisms fail silently instead of failing closed: (1) the ACL sandbox provisioning returns success, stores nothing, and the confined child keeps full write access — while the shipped package README states a FAT grant root "fails loudly"; (2) the file version token degenerates (2-second mtime quantization, a per-volume constant ctime, recycled inodes) so the "file changed since it was read" guard does not fire and an external same-size edit is silently overwritten. Both measured against the shipped 44.7.0 code and cross-checked against master @ 687f282e8625.

说明：本文不涉及已在 #3884 / #4981 / #5127 / #5704 / #7774 覆盖的 exFAT 硬链接发布缺陷（那条我在 #7774 里补了"44.7.0 仍未修 + 可用热补丁"）。这里只有社区尚未覆盖的两项。

环境

项	值
版本	DeepSeek Harness 桌面版 44.7.0（dsh release 0.2.1-rc.2，nodeVersion 24.21.0），更新通道 nightly
对照源码	deepseek-ai/deepseek-harness master @ 687f282e8625c6b8d11ff58211a90524be2e4317（2026-10-17T07:22:43Z）
工作卷	E: = exFAT，DriveType Fixed，Get-Volume 报 HealthStatus Warning / OperationalStatus Full Repair Needed
对照组	C: = NTFS
卷能力	fsutil fsinfo volumeinfo E: 不含 Supports Hard Links、Preserves & Enforces ACL's、Supports Reparse Points、Supports USN Journal；fsutil 8dot3name query E: → Error -2147024895: Incorrect function

---

发现 1：ACL 沙箱在不存储安全描述符的卷上授权成功、效果为零（安全相关）

1.1 实测（跑的是出厂 runner 与出厂 grant.ts/acl.ts，不是推断）

观察	exFAT 工作区根	NTFS 对照
provisioning（grantWrite / AclWriteGrant.add，即 SetEntriesInAclW + SetNamedSecurityInfoW）	返回成功，1–9 ms	返回成功
之后 icacls 读回	No permissions are set. All users have full control.（与授予前逐字一致）	Everyone:(CI)(DENY)(DC)、S-1-4-<hash>:(OI)(CI)(W,D,DC)、Mandatory Label\Low:(OI)(CI)(NW) 均在
read-only 模式下被约束的子进程	在工作区内创建并删除了文件（exit 0）；换一个无关的 exFAT 目录同样可增删	拒绝
workspace-write 模式下被约束的子进程	写入了未被授予的另一个 exFAT 目录（exit 0）	写未授权目录被拒（Access is denied.，exit 1）
写 NTFS 上未授权路径	被拒（exit 1）——受限令牌本身仍起作用	被拒
进程内 dsh-fs-sandbox 的路径围栏	仍然有效（纯路径判断，不依赖 ACL）	有效

一句话：令牌层（Low IL / WRITE_RESTRICTED）仍然生效，文件系统 ACL 层在 FAT 类卷上等于 0，于是"工作区内可写 / 工作区外不可写"这条边界对这些卷完全不存在；而没有任何一层会报错，UI 与模型侧看到的是一个"已经启用沙箱"的会话。

1.2 为什么它不会被发现（源码对照）

packages/sandbox/sandbox-local/src/index.ts
   98:  * sole candidate, so the product never probes; the probe exists for override
  164:  // a sole candidate, selected without a probe — its execution-time refusal
  166:  win32: ['windows-acl'],
  178:  const STATIC_ENFORCEMENT: Record<SelectedRunner['runner'], SandboxEnforcement> = {
  188:    'windows-acl': 'partial',
  515:  if (rest.length === 0) return { runner: first, enforcement: STATIC_ENFORCEMENT[first] }

• Windows 链上只有 一个 候选 → 走 515 行分支，功能探测 defaultProbeWindowsAcl 永不调用（98 行明确写了）。因此 SANDBOX_UNAVAILABLE 只在 runner 起不来时触发；"runner 起来了但内核不持久化 DACL"与"真正受约束的 NTFS 工作区"在代码里不可区分。
• enforcement 恒为静态表里的 "partial"（188 行）——它既不区分卷类型，也不区分"部分生效"与"完全没生效"。
• packages/sandbox/sandbox-windows-acl/src/grant.ts:92-96,107：幂等判断读的是 apply 之前的 DACL（"an already-standing exact ACE …"），acl.ts:131,154 的 GetNamedSecurityInfoW 也只在 read-merge 阶段；acl.ts:262 检查的是 SetNamedSecurityInfoW 的返回码。我在 acl.ts/grant.ts（master）里找不到 apply 之后回读期望 ACE 的校验——若它存在于其它模块，请指出。FAT 类卷正是"返回 ERROR_SUCCESS 但不持久化"的情形。

1.3 与出厂文档相反

packages/sandbox/sandbox-windows-acl/README.md:190：

Wide-directory and FAT-volume warnings are deferred; the FAT-class residue is unverified — the UI-side warnings are not implemented, a FAT volume as a grant root fails loudly, and a FAT-class target outside the granted roots stores no security descriptor …

前半句（警告未实现）与实测一致；但 "a FAT volume as a grant root fails loudly" 不成立：实测它 fails silently，且返回一个看起来完全正常的成功。README:204 也只把 FAT 列为"未决方向"，没有把它当作会让约束完全失效的安全前提。

1.4 建议（按代价从小到大）

1. apply 后回读校验：SetNamedSecurityInfoW 成功后，对同一句柄再 GetNamedSecurityInfoW 一次，比对期望的 capability-SID allow + world deny + Low label 三条 ACE 是否真的存在；不一致即视为该根未被授予。
2. 若判定为"卷不存储 ACL"，fail closed（命令直接不跑并报原因），或至少在 UI/模型侧显式告知：本工作区的 read-only / workspace-write 对命令行进程没有文件系统级约束（现在 partial 这个词把"完全失效"和"边缘未覆盖"混在一起）。
3. 用 GetVolumeInformationW 的 FileSystemName 做一次卷类型判定，把结论写进 sandboxMode 的可见信息里；顺带修正 README 190 行的表述。

相关但不同的已报问题（不构成重复）：#8409（NTFS 数据盘 grantWrite Win32 5 硬失败）、#2（非系统盘 ACL 初始化失败）、[Win] windows-acl … %TEMP% 卷无法设完整性标签、UNC/9P 工作区根 ERROR_INVALID_FUNCTION、[Security] Windows 沙箱 partial 边界对模型与运维不可见。本帖的独特点是：FAT 类卷上返回成功、零效果、零告警，并且文档明确断言它会 loudly fail。

---

发现 2：版本令牌在 2 秒时间戳卷上退化 → FS_STALE_VERSION 漏检 → 静默覆盖外部改动

packages/fs/fs-local/src/fsio.ts
   75: function versionOf(info: BigIntStats): FsVersion {
   76:   return FsVersion(`${info.dev}:${info.ino}:${info.size}:${info.mtimeNs}:${info.ctimeNs}`)

在 E:(exFAT) 上的实测：

事实	值
mtimeNs 精度	量化到 2 秒：500 ms 间隔连续采样 LastWriteTime 恒为 13:58:38.000；utimes 写入 .005 落到 :02
ctimeNs	全卷同一常数 1240428288000000000（对 12 个不同文件都一样）→ 该分量不贡献任何信息
ino	非零、互异，但会被回收：同一目录删除 25 个文件后重建，25 个 inode 里 8 个重复出现

结果（同尺寸外部改写，同一 2 秒刻度内）：

token after external write #1 : 2061096415:989658750976:14:1792072734000000000:1240428288000000000
token after external write #2 : 2061096415:989658750976:14:1792072734000000000:1240428288000000000   <- 内容已变，令牌逐字节相同
token after write #3 (跨过 2 s) : 2061096415:989658750976:14:1792072736000000000:1240428288000000000  <- 检测恢复正常

于是：agent 读文件 → 用户 / IDE / 另一个脚本在同一 2 秒刻度内做等长度改写 → agent 写回 → 不报 FS_STALE_VERSION，外部改动被静默覆盖（丢更新）。跨过一个刻度才正常。注意 fsio.ts:633-638 的 createIfAbsent 只在观察之后做 guarded 检查，因此这个窗口对 write（整文件替换）完全适用；edit 因需匹配 old_string 会偶然挡住一部分，但同尺寸且文本仍匹配的情况同样会静默通过。

与已报问题的区别：#5432/#JNNarrator（macOS：ctime 进入判据导致过多误报）、JohnMikron（NTFS 纳秒抖动导致误报）都是 false positive 方向；本条是 false negative，后果是丢用户改动，且它发生在"agent 与外部编辑器同时工作"这一非常常见的场景。

建议：观察时一并记录内容摘要（writeText 已经会读 before 基线，成本几乎为零），stale 判据用 sha256 + size + mtime 而不是纯 stat；或在探测到"卷无亚秒时间戳 / ctime 恒定"时自动降级为哈希比较。另外 ino 会被回收这一点，也影响任何把 ino 当持久身份的地方（containment 回退、spill 去重、持久化 generation 见证）。

---

复现材料（可全部提供）

• 出厂 bundle 与 master 源码的行号对照均已在正文列出；asar 内 sha256：dsh-fs-local/lib/index.js 在 44.0.0 与 44.7.0 完全相同（41 311 B，63fbb41d2c33e07111884b798be507e68c2752acab8249c821c20ade436e894f）。
• 脚本：ACL 授予前后 icacls 对照、受限子进程增删测试、fsutil fsinfo volumeinfo 对照、版本令牌逐字节对照。
• 数据文件：400 次 stat 探针 / 32 MB 写入的两卷计时（元数据 11 ms vs 4 ms，写入 33 ms vs 58 ms）。

如果官方希望我把任一项做成可提交的补丁或更细的实验（例如按 ABI 枚举 SetNamedSecurityInfoW 在 exFAT 上的实际返回与持久化结果），我可以直接补。

[PerryLink]

发现 1 我核到了一处README 自相矛盾，这比我原本预期的更支持你的判断；发现 2 的机制组成也对得上。

发现 1：README 一边说 "fails loudly"，一边说 "not implemented"

packages/sandbox/sandbox-windows-acl/README.md 里两句话直接冲突：

• :190 —— "a FAT volume as a grant root fails loudly, and a FAT-class target outside the granted roots stores no security descriptor; its effective integrity label is assigned by the system rather than recorded on the object, so the label layer's behavior there is untested. FAT stays legacy residue."
• :204 —— "The warn-only posture for unusually wide directories and FAT-class volumes is documented in the limitations above but not implemented"

所以 README 自己就同时写着"会响亮地失败"和"没实现"。你的实测（授权成功、零效果）正是在裁决这两句里哪一句是真的 —— 而且从代码看，答案倾向于 :204：

packages/sandbox/sandbox-windows-acl/src/grant.ts 是 fail-closed 的，但它的 fail-closed 只覆盖 Win32 调用返回错误（:8 注释 "Fail-closed: add throws on any grant failure"，实现是 throwLastError / AggregateError）。文件里没有 GetVolumeInformation，也没有任何卷能力探测。也就是说：SetNamedSecurityInfoW 在 exFAT 上返回 ERROR_SUCCESS 却什么都没存 —— 这不是一个 Win32 错误，因此 throwLastError 永远不会被触发，"响亮失败"根本没有落点。

这一点值得作为报告的主证据：不是"实现有 bug"，是"承诺与实现不一致，且实现里缺少做出该承诺所需要的探测"。修法也随之明确：grant 之前查一次卷是否 Preserves & Enforces ACL's（GetVolumeInformation 的 FILE_PERSISTENT_ACLS），不支持就按 fail-closed 抛出，和现有 throwLastError 同一条路。

另外要注意你实测时工作区根到底是不是 E: 本身：README :190 对"grant root 是 FAT 卷"和"granted roots 之外的 FAT 目标"给了两句不同的话（前者承诺失败，后者承认"不存储安全描述符、标签层未测"）。如果 E: 只是工作区内的子目录，README 只承诺了一半，你的结论要收窄到"子目录"那一半 —— 这个区分会让报告更难被反驳。

发现 2：版本令牌的组成确实会在 exFAT 上退化

packages/session/session-persistence-jsonl/src/index.ts 的物理 revision 是 dev:ino:size:mtimeNs:ctimeNs 五元组。你的三条观察逐条对得上：

• mtime 2 秒量化 ⇒ mtimeNs 的纳秒部分恒为 0，同一 2 秒窗口内的两次同尺寸改写不可区分；
• ctime 是每卷常量 ⇒ 该分量恒等，等于白占一位；
• inode 回收 ⇒ ino 在删除/重建后可能重复。

三者叠加后，五元组里真正有效的只剩 size 和 2 秒粒度的 mtime。任何同尺寸、同窗口的外部改写都不会让"文件已变"的守卫开火 —— 这正是你描述的静默覆盖。这一条和发现 1 无关，是独立的缺陷，建议分开写：前者是安全边界（沙箱失效），后者是数据完整性（覆盖写），受理路径也不同。

两点建议

1. 把 README 的两句话并列贴出来。 :190 与 :204 的矛盾是你这条报告最有说服力的部分，比贴实测表格更让维护者无法回避。
2. 发现 2 的严重度被低估了：它不只影响"外部同尺寸编辑"，也影响同一个 DSH 进程之外任何工具对会话文件的改写（备份还原、同步盘、杀毒软件重写）。在一个 2 秒粒度的卷上，这意味着这些工具造成的改动可能被守卫静默放行。