传完再检查为何太晚？LXD 迁移流的文件写入边界
背景与时效说明
Canonical LXD 公告发布于 2026-09-25，超出本次 72 小时时窗。由于严格时窗内足够完整且不重复的漏洞主题不足，本文作为近期技术补充，不声称是今日新披露。
公告引用 Incus 原始公告，部分正文沿用 Incus 名称与版本描述。本文采用 LXD 包级修复表，不把正文中的 Incus 7.3 版本号混入 LXD 升级建议。
技术原理：流不是静态文件列表
官方描述的核心是迁移源可以影响接收端写入路径；接收工具可能跟随先前建立的符号链接，使后续条目越过预期目录。传输结束后的链接检查无法撤销已发生的写入。风险涉及实例或自定义卷的迁移，要求具备创建权限或能够成为目标接受的迁移来源。
**工程分析：**如果测试仅验证最终目录结构，就会漏掉过程中短暂存在但已经产生副作用的路径。类似地，只在开始时检查一次父目录，也不能证明后续路径解析使用的仍是同一个对象。
可将安全目标写成：每一次写入都必须被限制在预期资源范围内，而不是"传完以后看起来没有危险链接"。隔离执行环境、受约束的路径操作和迁移来源授权分别解决不同问题，不能互相替代。
影响范围与修复表
LXD 公告以 >=4.0 概括受影响历史，并列出分支修复版本：
| 分支 | 官方修复版本 |
|---|---|
| 4.0 | 4.0.14 |
| 5.0 | 5.0.10 |
| 5.21 | 5.21.8 |
| 6.9 | 6.9-bf243da |
| 6.10 | 6.10 |
不能把 >=4.0 机械理解为这些修复版本也受影响。应结合修复表、安装渠道和回补情况判断。公告区分不同接收机制：不能从某种优化传输不受该路径影响，推导整台主机所有迁移操作安全。
官方描述后果可达宿主任意文件写入，严重时导致主机失陷；本文没有验证实际环境，不把每一次迁移写成攻击，也不提供迁移载荷。核验的一手材料未确认现实利用活动。
无文件操作的时序模型
python
entries = [('data', 'ordinary'), ('link', 'redirect'), ('data', 'later')]
def postcheck_model(stream):
effects = []
for kind, name in stream:
effects.append((kind, name))
accepted = not any(k == 'link' for k, _ in stream)
return accepted, effects
def guarded_model(stream):
effects = []
for kind, name in stream:
if kind != 'data':
return False, effects
effects.append((kind, name))
return True, effects
ok, events = postcheck_model(entries)
assert not ok and ('data', 'later') in events
ok, events = guarded_model(entries)
assert not ok and ('data', 'later') not in events
print('side-effect timing model passed')模型用事件列表替代文件系统，只证明检查顺序。它不能证明真实迁移安全：合法符号链接、并发状态、存储驱动语义都比模型复杂。也不要据此给生产代码简单添加"禁止所有链接"就宣称完成厂商修复。
研发与安全团队行动清单
P0：收紧来源并升级
按部署分支升级，暂时只允许可信客户端创建实例和自定义卷，只从可信服务器迁移，这是官方提供的临时思路。可信应由身份、权限和管理责任证明，而不是仅凭内网地址。
P1：按阶段验证
覆盖主卷、快照、刷新与失败重试，并确认每一阶段的接收路径。测试应在完全隔离的自有环境进行，使用无敏感标记，检测是否出现预期目录之外的操作。不要在生产主机试验越界写入。
P2：让审计可还原过程
记录迁移发起者、来源、项目、存储驱动、起止时间和失败阶段。若存在可疑迁移，应按事件响应流程保全证据，检查宿主完整性；不能仅删除迁移实例就假设潜在宿主写入已经被撤销。
开发团队审计副作用时，可以从实际文件操作向上反查授权和路径约束。特别关注"开始前校验、结束后校验、中间交给外部工具"的接口，明确谁在操作发生时维持边界。
总结
流式导入的安全性取决于过程约束。事后检查有诊断价值，却不能充当写入前防护。修复验收应覆盖迁移全生命周期，而不是只检查最终对象。