恶意文件如何被 claude-obsidian 的归档防御逐关击退
【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian + Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathy's LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidian
claude-obsidian 是一个自组织的 AI 第二大脑：把任意来源的资料丢进去，Claude 负责读取、建立链接，并归档成一组互相引用的 Markdown 笔记，最终沉淀为可在 Obsidian 中反复查询的知识图谱。由于归档入口直接吞下外部文件，归档安全贯穿了它的全部实现——项目把每一个进入inbox/的文件都当作潜在的敌意输入来对待。
这篇文章不按"层层设防"的清单来写，而是跟着一个恶意文件走一遍完整的闯关过程：它在文件名校验、符号链接审计、内容寻址存储、并发锁这些关卡分别撞上什么机制，又被哪个错误码击退。所有机制均可在仓库代码中直接核对。
🧾 文件与路径先过"清洗"
恶意载荷最常藏在名字和路径里。源文件在接触归档流程前，名字要先过一遍_validate_filename：它拦截控制字符与不可见格式字符（零宽字符、换行）、首尾空格、以点或空格结尾的名字、Windows 保留名（CON、COM1、NUL等），并要求名称完成 NFC Unicode 归一化、长度不超过 240 字节。任何一条不满足都会抛出UNSAFE_FILENAME——这些规则防的是肉眼看不见的字符和在不同操作系统上行为不一致的名字。
路径本身还有独立的词法规则。配置项里的收件箱目录由_validate_relative_directory校验：拒绝绝对路径、反斜杠、"."/".."段，a/../b这类未规范化写法直接以INVALID_CONFIG_PATH失败。事务层的_normalize_vault_path更严格：控制字符或反斜杠返回INVALID_WRITE_PATH，未规范化的路径返回NONCANONICAL_WRITE_PATH，非 NFC 名称返回NONCANONICAL_UNICODE_PATH。
大小写与重音别名如何被排除
在不区分大小写的文件系统上，Note.md与NOTE.MD实际是同一个文件，攻击者可以用这种别名混淆权限判断。_assert_no_existing_portable_alias会枚举目标路径同目录下的兄弟项，只要发现 NFC + casefold 之后与写入路径同名的既有文件，就抛出CASEFOLD_PATH_ALIAS，把歧义挡在写入发生之前。
🔗 符号链接逐段拦截
符号链接相当于"别名门"：名字指向库内，实际通向库外。claude-obsidian 对归档链路上的符号链接采取零容忍，覆盖四个位置，且 Windows 上的 junction 和挂载点也按符号链接同等处理（见is_name_surrogate）。
| 机制 | 检查位置 | 错误码 |
|---|---|---|
| 收件箱与原始仓库根目录是否为符号链接 | discover_files | SOURCE_ROOT_SYMLINK |
| inbox 内任意目录/文件条目是符号链接 | discover_files | SOURCE_SYMLINK |
.raw内容寻址存储目录及其既有副本 | _planned_destination、_find_existing_capture | RAW_STORE_SYMLINK |
| 事务写入路径的每一段中间目录 | _safe_vault_path | SYMLINK_WRITE_PATH |
词法合法不等于安全：a/b.md里的a可能是指向系统其他位置的别名。_allowed_source_path会沿路径逐段检查中间目录，源文件即使自身无害，只要"穿过"了某个别名目录进入收件箱，就以SOURCE_OUTSIDE_INBOX被拒（L614-L624）。最终一道兜底是assert_within：它在真实文件系统上解析符号链接，确认最终落点仍在库内，否则抛出PATH_OUTSIDE_VAULT。
📦 预算硬限与内容寻址的不可变仓库
资源耗尽是另一类攻击：海量小文件或超大文件可以在归档前拖垮磁盘。批次进入任何 IO 之前要先过CaptureBudget：单批最多 100 个文件（COUNT_BUDGET_EXCEEDED）、单文件不超过 64 MB（FILE_BUDGET_EXCEEDED）、整批不超过 256 MB（TOTAL_BUDGET_EXCEEDED）；捕获队列文档另有 8 MB / 4096 条的上限（L68-L69）。这些限制属于"失败即中止"，不是提示性阈值。
通过预算的文件随后被复制为<SHA-256 摘要>.<扩展名>存入.raw/captured/，扩展名不在白名单内时统一落到.bin（L885-L890）。这个命名方案自带两层校验：
- 哈希期间的替换检测：
source_identity在计算摘要前后各取一次文件的 inode、大小、修改时间签名，若文件在读取过程中被换掉，抛出SOURCE_CHANGED冲突（L703-L705），保证进入仓库的就是检查时看到的那份字节。 - 重复归档的字节复核：
_find_existing_capture发现同摘要的旧副本时会重新计算其哈希，副本"名字对但内容不对"说明仓库被外部改写，抛出IMMUTABLE_SOURCE_CONFLICT。
原始资料区因此是只创建、永不修改的：任何已有副本必须与摘要完全一致，否则整批操作失败。
🚦 并发冲突：锁、所有权令牌与确定性回滚
多进程同时修改同一个库，会出现两个进程互相覆盖的情况。捕获队列为此使用目录型锁CaptureQueueLock：锁目录以原子方式创建，创建失败说明已有持有者（超时后抛QUEUE_LOCK_TIMEOUT，L1545-L1549）；持有者把 pid、主机名和随机 token 写入owner.json，释放前回读校验 token，发现身份不符即抛QUEUE_LOCK_OWNERSHIP_LOST，防止锁被并发偷换。死锁恢复刻意保守：只有确认持有进程已死且锁超龄（默认 3600 秒）才允许清理，且清理前还要复查锁身份未变。
事务层的MutationLock采用同一套所有权模型（LOCK_OWNERSHIP_LOST），并在此基础上提供"预检哈希 + 持久日志 + 原子替换 + 回滚"：每个写入都记录预期哈希，回滚删除文件前由_confined_vault_unlink重新校验目标文件的字节与 inode，发现被替换过就抛ROLLBACK_TARGET_CHANGED，绝不删掉不属于自己的文件。所有此类冲突都归入CaptureConflict错误家族，以确定性错误码暴露，而不是静默失败。
🛡️ 外部 URL 的 SSRF 边界
本地归档之外，外部 URL 适配器同样被锁死。validate_https_url只接受 HTTPS（URL_SCHEME_FORBIDDEN）；_validate_public_host拒绝localhost、.internal、169.254.*等非公网主机（URL_PRIVATE_HOST）；validate_redirect_chain则要求重定向不得离开已批准的主机白名单（REDIRECT_HOST_FORBIDDEN）。外部动作只能生成"惰性计划"，必须用户明确同意才执行。
克隆仓库https://gitcode.com/GitHub_Trending/cl/claude-obsidian后，按 docs/install-guide.md 初始化一个独立知识库，把文件放进inbox/即可触发上述全部校验；归档事务的具体规则另见 skills/wiki/references/operation-transactions.md。这套体系的设计取向很一致：任何一步遇到不确定状态，宁可抛出带错误码的冲突停下来，也不在模糊中继续写入——对把文件交给机器加工的工具来说，这比"尽量完成"更接近用户真正需要的安全感。
【免费下载链接】claude-obsidianSelf-organizing AI second brain for Obsidian + Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathy's LLM Wiki pattern.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-obsidian
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
