[BUG] 在WSL下使用workspace write模式时，由于/dev/dxg被隐藏，无法使用gpu

[Entoryvekum]

workspace write模式没有完全dev访问，而在wsl中使用cuda则需/dev/dxg。这会导致dsh无法使用cuda。

[zoahdev]

核验确认，而且问题比"workspace-write"更宽：两个沙箱档位都让 /dev/dxg 不可用（当前 main HEAD 99f6f02）。

机制（packages/sandbox/sandbox-local/src/profiles.ts）

1. bwrap 档（:16-20）：基础参数是无条件的 --ro-bind / / --dev /dev --proc /proc。bwrap 的 --dev /dev 会用全新 devtmpfs 覆盖宿主 /dev（只含 null/zero/full/random/urandom/tty 等基础节点），/dev/dxg（WSL2 的 dxgkrnl 半虚拟化 GPU 设备）根本不存在于新 tmpfs 里——所以 workspace-write 模式下 bash 里 ls /dev/dxg 就是没有。这不是 workspace-write 特有问题，read-only 也一样。

2. Landlock 退路（:27-33）：readOnly: ['/'] + readWrite 只有 /dev/null（workspace-write 再加 /tmp 和 workspaceRoot）。WSL 里如果没装 bwrap 走 Landlock，/dev/dxg 只读可开，但 CUDA 对 dxgkrnl 设备做 ioctl 需要 O_RDWR 打开，会被 Landlock 拒绝。

所以两种情况是：bwrap 档"设备不存在"，Landlock 档"存在但不可写"。CUDA 需要的 /usr/lib/wsl（libcuda.so.1 等）在 --ro-bind / / 下可读，缺口恰好就是 /dev/dxg 这一个设备节点。

修复建议（安全优先）

在 sandbox-local 的 Config 增加一个可选的设备透传列表（默认空），两个档位各自实现：

// Config 增加
extraDevPaths?: string[]  // 默认 []

// bwrap 档：对每个存在的路径追加 --bind（只透传指定节点）
for (const p of policy.extraDevPaths ?? []) if (existsSync(p)) args.push('--bind', p, p)

// Landlock 档：追加到 readWrite（不是 readOnly）
readWrite.push(...(policy.extraDevPaths ?? []).filter((p) => existsSync(p)))

WSL 用户配 extraDevPaths: ['/dev/dxg'] 即可恢复 CUDA，非 WSL 平台默认值不变、零影响。

不建议全局 --dev-bind /dev /dev：那会把宿主 /dev 的块设备（sda/nvme）、随机设备全量带入沙箱，直接削弱现有"最小 /dev"隔离设计——透传列表才是和 Landlock/Seatbelt 授权模型一致的做法。

回归测试建议：e2e 在存在 /dev/dxg 的环境断言沙箱内 test -e /dev/dxg（无该设备的 CI 平台跳过），防止将来有人把 bwrap 参数改回裸 --dev /dev 时回归。这个机制顺带说明：WSL 下其它 dxgkrnl 设备（如 /dev/wslg）也会被同样藏起来，透传列表是通用解法。

[weijiafu14]

@zoahdev 的核验很完整（bwrap 的 --dev /dev 用新 devtmpfs 覆盖宿主 /dev，/dev/dxg 根本不存在；Landlock 退路则是存在但只读，而 CUDA 对 dxgkrnl 做 ioctl 需要 O_RDWR）。设备透传列表这个方向我也同意。

补一条评审这个提案时会关心、但可能没人说的事：在 WSL 这个具体平台上，加这个洞的边际风险比它看起来小得多——因为那里的沙箱已经有一个更大的洞。

WSL2 上的 workspace-write 已经可以被完全穿透

#3045 是一份已复现的报告：在 WSL2 上，沙箱内调用 powershell.exe / cmd.exe 会经 WSL interop 启动一个 Windows 原生进程——它不经过 bwrap 的挂载命名空间（bwrap 只约束 Linux syscall），以当前 Windows 账户身份运行，对 C:/D:/E: 所有盘符有完整读写权限。那份报告里实测在 workspace-write 下删掉了 D 盘 26.8GB，零审批。

把这两件事并起来看：

	加设备透传之前	加之后
沙箱内能读写工作区外的 Linux 文件吗	否	否（不变）
沙箱内能读写整个 Windows 盘符吗	能（经 interop，#3045）	能（不变）
沙箱内能用 /dev/dxg 跑 CUDA 吗	否	是

在 WSL 上，workspace-write 今天已经不是一条真实的边界（除非用户按 #3045 的建议关掉了 /etc/wsl.conf 的 interop）。所以"透传一个 GPU 设备节点会削弱沙箱"这个顾虑，在这个平台上的实际增量很小。

这一点值得写进提案，因为它把评审的问题从"该不该给沙箱开洞"变成了两个更清楚的问题：

1. 默认空的、需要显式配置的设备列表，在沙箱确实生效的平台（原生 Linux + bwrap）上风险如何？——这是真问题，值得按 @zoahdev 的建议做成显式 opt-in；
2. 在 WSL 上，用户真正该知道的是 [Security] WSL2 interop 通道完全穿透 workspace-write 沙箱：bwrap 只读挂载对 Windows 侧进程无效（含 PoC） #3045——他以为自己受 workspace-write 保护，实际不是。

但这话得两面说

我不希望上面那段被读成"反正都漏了，随便开"。诚实的结论是两条：

• 对这个提案：WSL 场景下设备透传的边际风险确实小，因为大头的洞在别处；
• 对 WSL 用户：这恰恰说明不该把 DSH 的 workspace-write 当成 WSL 上的安全边界。真要隔离，得在 OS 层（关掉 interop、独立用户账户、容器或虚拟机），而不是靠沙箱档位的选择。

这两条不冲突，但只说第一条就是误导。

一个实现上的建议

@zoahdev 提的 extraDevPaths（默认空）形状是对的。补一句：这个列表生效时，值得让它对模型和用户可见。

理由来自 #1331 提的那件事——windows-acl 档本身标着 enforcement: 'partial'，但这些边界对模型和运维都不可见，受限运行看起来和完全受限一模一样。设备透传是同一类：一个"我以为我在沙箱里"的进程，实际拿到了一个可以做任意 ioctl 的设备节点。

所以建议：配置了 extraDevPaths 的运行，在结果里带一行类似 [sandbox: device passthrough — /dev/dxg] 的声明。成本接近零，而它保证了沙箱的实际强度永远和它自己宣称的一致——这条原则值得对所有削弱沙箱的配置项一体适用，而不只是这一个。

边界与利益相关

我们不修 DSH 自家组件——sandbox-local 的 profiles、bwrap/Landlock 档位都在 DSH 里。上面全是提案评审角度的意见和跨帖串联。

我没有 WSL 环境，没有复现过 /dev/dxg 这条，也没有复现过 #3045——第一节完全建立在那份报告和 @zoahdev 的源码核验上。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——你要的是 DSH 沙箱能透传一个设备节点，那是 DSH 和 bwrap/Landlock 层的事，装什么插件都不改变 --dev /dev 挂出来的是什么。