JOJO
4d9b709a9e
工作流运行时： - 状态机与编排：modules/workflow_state_manager.py + server/workflow_flow.py （激活快照/阶段推进/审核节点/分支决策/柔性通知/max_stage_rounds 撞限询问） - 五个工具（activate/report_stage/choose_branch/get_status/deactivate） 与 REST API（server/workflow_runtime_api.py） - 前端：QuickDock 工作流窗口（三段式进度，推进/驳回/完成/退出动画）、 slash 菜单激活与退出、轮询事件消费、进入对话状态回填 - 审核：modules/workflow_review_agent.py（pass/reject 把关节点） 审核智能体统一配置： - 个人空间新增「审核智能体」标签页：自动审批/目标/工作流三个审核智能体 统一选择模型+思考模式+超时/轮次参数 - modules/review_agent_config.py 统一解析（复用子智能体模型库）， 废除独立 json 配置（auto_approval/goal_review/workflow_review） - goal 审核接入 max_rounds 上限（原常量未接线）；workflow 审核硬编码 6 轮改为可配 联调修复： - /new 空对话激活：后端自动创建对话并完整继承模式参数 （work_mode/permission/execution/reasoning_effort，修复思考模式丢失） - 激活/通知消息 starts_work=True，恢复智能体回复头部与工作计时 - 节点目录改为从开始节点拓扑遍历（修复按保存顺序显示错乱） - QuickDock 乐观掩码不再掩盖工作流实时状态（修复 /new 激活窗口瞬关+延迟瞬开）； /new 路由不套用全局内容缓存（修复空对话展开空白数秒后收回） - 工作流完成先广播完成态快照再摘牌，窗口播完落定+退出动画再收起 - 激活提示中的工具名修正为 report_workflow_stage
199 lines
6.2 KiB
Markdown
199 lines
6.2 KiB
Markdown
# 宿主机沙箱与权限系统说明（2026-05）
|
||
|
||
本文档用于完整说明当前项目在 **宿主机模式（`TERMINAL_SANDBOX_MODE=host`）** 下的安全执行机制，包括：
|
||
|
||
- OS 级沙箱执行
|
||
- 执行环境（Execution Mode）
|
||
- 权限模式（Permission Mode）
|
||
- 路径授权（Path Authorization）
|
||
- `run_command` / `terminal` / `sub_agent` 的实际行为
|
||
|
||
---
|
||
|
||
## 1. 设计目标
|
||
|
||
在保留宿主机开发效率的前提下，降低误操作与越权风险，核心目标是：
|
||
|
||
1. 默认命令执行必须经过系统沙箱（而非裸 host）
|
||
2. 权限控制尽量由执行层强制（减少“猜指令”误判）
|
||
3. 对高风险写操作引入用户审批与单次授权机制
|
||
4. 保持可运维：可配置、可回退、可解释
|
||
|
||
---
|
||
|
||
## 2. 两层控制模型
|
||
|
||
当前系统分为两层控制，且叠加生效：
|
||
|
||
### 2.1 权限模式（产品层）
|
||
|
||
- `readonly`
|
||
- `approval`
|
||
- `auto_approval`
|
||
- `unrestricted`
|
||
|
||
作用：决定工具是否允许调用、是否先只读执行、是否需要用户审批。
|
||
|
||
### 2.2 执行环境（系统层）
|
||
|
||
- `sandbox`（默认）
|
||
- `direct`
|
||
|
||
作用：决定进程最终在 OS 沙箱中执行，还是直接在宿主机执行。
|
||
|
||
> 推荐默认：`permission_mode=approval` + `execution_mode=sandbox`
|
||
|
||
---
|
||
|
||
## 3. OS 级沙箱方案
|
||
|
||
宿主机模式下，默认执行环境为 `sandbox`，各系统实现如下：
|
||
|
||
- **macOS**：`sandbox-exec`
|
||
- **Linux**：`bubblewrap (bwrap) + seccomp`
|
||
- **Windows**：`WSL2`
|
||
|
||
若宿主机沙箱不可用，关键执行路径会拒绝执行，不允许静默回退到裸 host。
|
||
|
||
---
|
||
|
||
## 4. 路径授权模型
|
||
|
||
路径授权分两类：
|
||
|
||
1. **可读可写路径（writable_paths）**
|
||
2. **仅可读路径（readable_extra_paths）**
|
||
|
||
语义：
|
||
|
||
- 可读集合 = 可读可写 + 仅可读
|
||
- 可写集合 = 可读可写
|
||
|
||
前端“路径授权”弹窗支持这两类路径的维护（新增/编辑/删除），并由后端策略模块统一读取。
|
||
|
||
---
|
||
|
||
## 5. 各权限模式的实际行为
|
||
|
||
## 5.1 readonly
|
||
|
||
- `run_command`：允许调用，但在**只读沙箱**执行
|
||
- 若命令触发写入：由系统返回权限拒绝（例如 `Operation not permitted`）
|
||
- `write_file` / `edit_file` / 其他写入类工具：直接拒绝
|
||
|
||
## 5.2 approval
|
||
|
||
- `run_command` 采用“两段式”：
|
||
1) 先在只读沙箱执行
|
||
2) 若出现权限拒绝，再发起前端审批
|
||
3) 审批通过后，仅该次命令以可写沙箱重试
|
||
- 工具结果返回“最终执行结果”（即重试后结果），不会把中间权限拒绝作为最终结果返回给模型
|
||
- 审批拒绝或超时：返回 rejected，不执行写入重试
|
||
|
||
## 5.3 auto_approval
|
||
|
||
- `write_file` / `edit_file`：
|
||
- 目标路径在当前工作区内：直接执行
|
||
- 目标路径不在当前工作区内：进入审批流程
|
||
- `run_command` 采用“两段式”：
|
||
1) 先在只读沙箱执行
|
||
2) 若出现权限拒绝，触发自动审批（审批智能体）
|
||
3) 自动审批通过后，仅该次命令可写重试
|
||
- 自动审批拒绝：返回“工具调用被拒绝 + 原因”，主智能体继续下一步（不强制中断整轮任务）
|
||
- 用户可随时人工接管审批结果（同意/拒绝/切换无限制）
|
||
|
||
## 5.4 unrestricted
|
||
|
||
- 权限模式层不拦截工具
|
||
- 是否沙箱执行取决于执行环境：
|
||
- `sandbox`：仍在 OS 沙箱中执行
|
||
- `direct`：宿主机直接执行
|
||
|
||
---
|
||
|
||
## 6. 执行环境（sandbox/direct）细节
|
||
|
||
## 6.1 sandbox（默认）
|
||
|
||
- 命令在 OS 沙箱执行
|
||
- 配合路径授权限制写边界（与读边界策略）
|
||
- 可结合权限模式实现只读优先与单次升级写权限
|
||
|
||
## 6.2 direct（高权限）
|
||
|
||
- 命令直接在宿主机执行
|
||
- 仅建议临时用于必须操作
|
||
- 切换后一直生效，无自动回退机制（2026-07 已移除原 TTL 自动回退）
|
||
|
||
---
|
||
|
||
## 7. 关键工具与执行路径
|
||
|
||
### 7.1 run_command
|
||
|
||
- 支持权限模式联动（readonly/approval/unrestricted）
|
||
- 在 host + sandbox 下可走只读沙箱或可写沙箱
|
||
- 在 approval 模式可触发“权限拒绝 -> 审批 -> 单次可写重试”
|
||
- 在 auto_approval 模式可触发“权限拒绝 -> 自动审批 -> 单次可写重试”
|
||
|
||
### 7.2 terminal 系列
|
||
|
||
- 终端会话从启动时就在沙箱里（host+sandbox）
|
||
- 同一会话中的后续输入继承该会话沙箱上下文
|
||
- 若路径授权更新，需要新开终端会话才能让该会话使用新策略
|
||
|
||
### 7.3 子智能体（sub_agent）
|
||
|
||
- 宿主机下已接入执行环境策略：
|
||
- `sandbox`：子智能体进程经宿主机沙箱启动
|
||
- `direct`：直接宿主机启动
|
||
- Docker 模式维持容器执行
|
||
|
||
### 7.4 自动审批（approval agent）
|
||
|
||
- 自动审批由独立审批智能体执行（与主智能体分离）
|
||
- 配置：个人空间「审核智能体」页统一设置（personalization.json 的 `review_agents.auto_approval`），模型复用子智能体模型库；旧的 `config/auto_approval.json` 已彻底废除
|
||
- 审批智能体可调用能力：
|
||
- `run_command`（用于只读核查）
|
||
- 审批决策工具（approved / rejected + reason）
|
||
- 调试开关（代码变量）：
|
||
- `modules/approval_agent.py` 中 `DEBUG_SAVE_APPROVAL_AGENT_TRANSCRIPT`
|
||
- 开启后记录到 `logs/approval_agent/`
|
||
|
||
---
|
||
|
||
## 8. 配置与运行建议
|
||
|
||
## 8.1 推荐默认策略
|
||
|
||
1. `TERMINAL_SANDBOX_MODE=host`
|
||
2. 执行环境默认 `sandbox`
|
||
3. 权限模式默认 `approval`
|
||
4. 路径授权默认最小化（工作区 + 临时目录）
|
||
|
||
## 8.2 何时使用 direct
|
||
|
||
仅在以下场景短时开启：
|
||
|
||
- 明确需要系统级高权限访问
|
||
- 沙箱下无法完成且替代方案不可行
|
||
|
||
执行完成后应尽快回到 `sandbox`。
|
||
|
||
---
|
||
|
||
## 9. 已知权衡
|
||
|
||
1. `run_command` 若严格收紧读路径，可能导致大量系统命令可用性下降
|
||
2. 权限拒绝识别基于错误特征，需持续优化误判/漏判边界
|
||
3. 不同 OS 的沙箱能力不完全对齐（Windows 侧为 WSL2 路径）
|
||
4. Docker 模式下目前不存在与宿主机同等的 OS 只读沙箱机制；`sandbox_write_access=False` 不会提供同等级只读隔离（需后续补充容器侧只读策略）
|
||
|
||
---
|
||
|
||
## 10. 文案与产品约束
|
||
|
||
- 面向用户的提示词仅描述“能力边界”和“可操作建议”
|
||
- 不暴露内部实现细节（如内部判定逻辑、实现细节名称）
|
||
- 审批流程文案要强调“单次授权、最小权限、可回退”
|