|
|
028e42b036
|
fix(plugins): 出站主机授权两处真缺陷 —— 已启动 worker 看不到新授权、授权不落盘
生产实证：channels 插件的 auth/state 在主机已授权后仍被拒
（auth/state 失败: host "copilot.tencent.com" is not an allowed outbound destination），
而 /api/plugins/channels/kernel 明明显示 hosts_granted=26。
缺陷一（授权对已启动 worker 无效）：
httpAllowlist 是不可变快照；bootPluginState 在 worker 启动时把指针绑进 Lua
闭包，闭包与 worker 同寿。GrantExtraHosts 之后 ps.allowHTTP 被**整个换新**
（newHTTPAllowlist 返回新实例），已启动的 worker 仍持旧指针 → 授权接口返回
ok、设置页显示已批，请求却继续被拒。分片 VM（plugin_shard.go）同样中招。
修法：allowlist 改为带 RWMutex 的**可变共享对象**，GrantExtraHosts 与
rebuildOutboundAllowlistLocked 原地 add —— 所有闭包立即看到新授权，worker
无需重建。rebuild 从"替换实例"改为"原地折叠"，并在注释里写明为什么。
缺陷二（授权不持久化）：
.kernel-perms.json 只写 actions；hosts 授权只存在运行态 map，重启即失。
设置页看不出异常（actions 有持久化，读起来像"都持久化了"）。
修法：文件行改为 jsonPluginPolicy{actions,all_read,hosts}（旧文件向后兼容，
纯 actions 行照常解析）；Load 恢复 extraHosts；Save 把每个插件的 host 授权
与 actions 一起写入（支持"只批了主机、没批动作"的行）。
回归测试（internal/lua/plugin_http_test.go）：
- TestGrantExtraHostsVisibleToAlreadyBootedWorker：按事故顺序构造（先启动
worker → 再授权），断言同一批 worker 立即可用新授权 + 旧引用不再失效。
- TestHostGrantsPersistAcrossRestart：授权落盘 + 新 registry 读回 + 插件重载
后授权保留。
go test ./internal/lua/ 全绿；build/vet 通过。
|
2026-10-13 06:57:28 +08:00 |
|
|
|
74ec1e7874
|
refactor(lua): 内核回归六项职责 —— 登录/浏览器全部移入插件
用户钉死了内核的职责边界，本提交把越界部分全部拆除：
内核只做：加载适配器 · auto 调度 · 加载插件 · 调度插件 · 维护源与 key · 签发密钥
## 架构纠正（用户指出的根本错误）
我此前把信任模型弄反了。实测：插件 VM 的 os.execute/io.popen/package 全部可达
(true,true,true) —— 插件从来不是 OS 级沙箱。正确的边界是：
插件 可信（运维安装），非沙箱，有完整 OS 能力 → 平台知识/登录/浏览器归它
适配器 不可信（可被动态安装），请求级 → 沙箱归它（12 个内置适配器实测均不碰
os/io/package，后续沙箱化零风险，属独立一步）
## 删除（内核越界部分）
- plugin_browser.go 内核浏览器管理器（Xvfb/chromium/x11vnc/websockify
进程栈、回环监听器）—— 388 行全删，浏览器由插件用
os.execute 自己拉起（实测 spawn+reap 闭环可用）
- plugin_login.go 登录会话状态机 + LoginFlow 枚举 + VNC 全局门禁
—— 457 行全删。"登录"从内核概念中消失
- gateway/browser_proxy.go viewer 反代
- handlePluginLogin API 登录会话列表端点
- vnc_enabled 全局开关 改为 per-plugin 授权（见下）
## 新增（内核职责内的通用机制，无任何登录/浏览器语义）
- plugin_outbound.go 通用额外出站主机授权：插件声明 plugin.hosts（请求）
→ 运维在设置页逐个批准（授权）。与 kernel actions
同一"声明≠授权"模型。内核只知道白名单加减，不知道
host 被用来干什么
- on_unload 生命周期钩子 卸载是"调度插件"的一部分：内核在关闭插件状态前调用
插件导出的 on_unload，让它自清理外部资源。内核不知道
资源是什么（进程/句柄/远端会话都行）。带进程回收回归
测试 TestOnUnloadReapsPluginProcesses
## channels.lua 全量接管
- 登录会话自持：plugin.state.sessions（nonce 只在 begin 响应出现一次，
惰性过期清理）
- 服务端浏览器栈自持：spawnBrowser 用 io.popen 拉起 Xvfb/chromium/x11vnc/
websockify 并记 pid，reapBrowser 回收；on_unload 兜底
- 优先级阶梯（用户指定）：① 本机浏览器（给 URL）→ ② 自动化（轮询/nonce 回调）
→ ③ VNC 无头浏览器兜底（无浏览器系统/自动化无法完成的场景，如回环重定向
必须落在服务端）
- plugin.auth_hosts → plugin.hosts（语义泛化：出站主机授权与登录无关）
## 验收
- 全仓旧符号零残留（grep 权威确认，代码+注释+lua+测试）
- 内核非测试代码零厂商名
- build + vet 全绿；lua/core/gateway/types/scheduler/provider 全量测试通过
- channels 端到端（登录→凭据→add_source→模型可见）继续通过
|
2026-10-11 16:24:55 +08:00 |
|
