AST-based command decomposition：方案与安全边界（discussion）

[PerryLink]

目标：把一条 shell 行解析为命令树（管道 / 子 shell / 重定向），按「叶子命令 + 完整 argv」逐条过 allow/deny/ask 规则，让 permission-rules 从「整行匹配」升级到「结构化匹配」。

与现有 params 通配的关系：AST 分解是 params 层之上的第二判定面——先 params 后 AST，双面都过才放行；params 命中的规则仍以行级短路优先。

安全边界（本方案的核心约束）：

• 「规则写错即绕过」是 AST 分解新增的最大语义面：每个 AST 规则必须自带测试向量（rule + argv 样例 + 期望判定），未命中即 deny 的默认语义保持；
• 提供 dry-run 模式（只打印判定不执行）；
• 采用此前 @sjh9714 提出的共享 rule-syntax 测试向量格式（见 Proposal, shared rule-syntax test vectors between our two gates #4/Proposal, shared rule-syntax test vectors between our two gates #5），与 dsh-doublecheck 共用同一向量文件；
• 解析器只做语法层（分词 / 管道结构），不做命令语义仿真——沙箱与拦截归执行层。

范围外（首版不做）：别名展开、shell 求值仿真、跨行续行。

征求 @sjh9714 与 @weipeng1999 的意见，欢迎补充边界用例（如 xargs/sudo 包裹、$(...) 嵌套深度上限、多语句 ; 分段粒度）。

[sjh9714]

这个方向可行。我建议首版把下面几类情况设为显式边界。

• xargs 不能仅靠静态 AST 推导内层命令。实际 argv 来自 stdin，除非执行层能约束输入，否则应 ask 或 deny。
• sudo、env、command 等包装器应使用逐个审核的解包白名单。不要采用通用的“跳过第一个命令”规则。
• $(...) 应作为独立的可执行子树先判定，再判定外层命令。嵌套超过明确上限时应 ask 或 deny。
• sh -c 和 bash -c 只有在对子字符串递归解析并限制深度时才能继续分解。动态构造的字符串不能继承外层 allow。
• 重定向本身具有副作用。建议把目标路径和 append、truncate、read 等操作作为策略节点，而不只是检查叶子命令。
• 解析失败、空 argv、动态 argv、未支持的 shell 语法都不应回退到 allow。

共享测试向量里可以增加一个 phase 字段，用来区分 line、ast-leaf、redirection 和 nested-shell。这样两个项目对同一条输入产生不同中间树时，也能定位是解析差异还是规则差异。

[Cirn09]

或许可以考虑实现一个带审计能力的 bash

[weipeng1999]

或许可以考虑实现一个带审计能力的 bash

那就比较侵入式了233,其实真要搞可以考虑搞一个eBPF注入内核，在工作目录起unshare沙箱，然后给每个子智能体一个uid，从内核层面拦截文件操作。

[weipeng1999]

个人认为：

• xargs、parallel 这种argv来自stdin的，默认ask即可， 安全约束决定权交给用户
• sh -c 、bash -c 对子字符串解析比较困难（可能有注入的环境变量），看成整个的sh -c .* 进行ask或deny，不进行子字符串解析。默认进行ask或deny，最终决定权交给用户
• 重定向也许可以路由到原子的read/write动作 + bash操作，比如ls > a.log变成bash[command: ls]和write[a.log]
• 除了$(...)作为独立的可执行子树，类似的还有`...`、{...}、[...]、<(...)等等
• 解析失败应该整个部分视为一个原子做匹配，匹配失败则落回默认行为
• 只对完整命令进行1次ask，AST只在匹配时起作用

[weipeng1999]

AST方案建议只作为一种补充，用于确实能够通过部分证明整体安全性的场合，对于比较复杂的情况，感觉还是要利用auto-review让AI来审核

[PerryLink]

几位提的边界清单我全盘接受，尤其是「解析失败/空 argv/动态 argv 一律不回退 allow」和「动态构造字符串不能继承外层 allow」这两条——AST 分解的价值必须建立在 fail-closed 之上。首版实现按 @sjh9714 的清单收口：xargs/parallel 默认 ask、sudo/env/command 走逐项解包白名单、$(...) 作为独立子树先行判定、sh -c/bash -c 递归限深解析、重定向目标为 append/truncate/read 单独作为策略节点。共享测试向量加 phase 字段（line / ast-leaf / redirection / nested-shell）的方案同步采纳，这样两个项目对同一条输入产生不同中间树时可以直接定位是解析差异还是规则差异。@Cirn09 的审计型 bash 与 @weipeng1999 的 eBPF/unshare 属于下一层的执行级约束，超出本插件（审批缝之前）的职责边界，但作为方向已记录；AST 只做「能部分证明整体安全」的补充、复杂场景交给 auto-review 二审，与我的设计一致。实现进度会继续在本帖更新。

[Cirn09]

乱码了？

[PerryLink]

抱歉，我上一条评论是通过工具发布时编码出错，评论区显示的乱码并非本意。原文应为：

几位提的边界清单我全盘接受，尤其是「解析失败/空 argv/动态 argv 一律不回退 allow」和「动态构造字符串不能继承外层 allow」这两条——AST 分解的价值必须建立在 fail-closed 之上。首版实现按 @sjh9714 的清单收口：xargs/parallel 默认 ask、sudo/env/command 走逐项解包白名单、$(...) 作为独立子树先行判定、sh -c/bash -c 递归限深解析、重定向目标为 append/truncate/read 单独作为策略节点。共享测试向量加 phase 字段（line / ast-leaf / redirection / nested-shell）的方案同步采纳，这样两个项目对同一条输入产生不同中间树时可以直接定位是解析差异还是规则差异。@Cirn09 的审计型 bash 与 @weipeng1999 的 eBPF/unshare 属于下一层的执行级约束，超出本插件（审批缝之前）的职责边界，但作为方向已记录；AST 只做「能部分证明整体安全」的补充、复杂场景交给 auto-review 二审，与我的设计一致。实现进度会继续在本帖更新。

感谢指正。

[PerryLink]

Announcement: this design is now officially scheduled for implementation on the dsh-permission-rules roadmap.

The binding constraints are exactly the ones gathered in this thread: fail-closed first (parse failure / empty argv / dynamic argv never fall back to allow), audited wrapper allowlists, and xargs / parallel defaulting to ask/deny. The PoC will ship behind an opt-in gate with dry-run and phase-tagged test vectors, and audit evidence (resolved shell form + policy version) will precede a minor release.

Thanks everyone for the boundary cases — the thread stays open for more.

---

中文摘要：本方案已正式排期进入路线图。硬约束即本线程共识——fail-closed 优先、包装器审计白名单、xargs/parallel 默认 ask/deny；门控 PoC + dry-run + phase 测试向量先行，审计证据齐备后小版本发布。感谢各位的边界用例，讨论继续开放。