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来审核