Go 主机安全面试：Linux inotify 监控覆盖与溢出恢复
岗位场景
一台 Web 主机的 HIDS 用 inotify 监控站点目录。业务发布通过“写临时文件、重命名替换”更新文件，某天 Agent 报出队列溢出，之后站点又新增了子目录。客户问：“没有告警，是否说明没有落地 Web 后门？”答案是否定的：inotify 是变化提示，不是完整审计日志；队列溢出、未安装的子目录 watch 和 Agent 停机都会造成观察空窗。
面试重点不是背 API，而是解释覆盖范围、事件丢失、恢复对账和证据边界。下面只讨论 Linux 本地文件系统上的目录监控；网络文件系统及容器挂载视图需要单独验证。
高频面试题
1. 监听一个目录就能递归看到所有子目录吗？
简洁答案： 不能。inotify_add_watch 监听的是指定 inode；监听父目录能看到直接子项的名字变化，但不会自动监听已有或新建的子目录内部。
关键知识点： 初始扫描应给目标树中每个目录安装 watch；发现新目录后也要安装 watch 并扫描其内容。目录在“创建”和“安装 watch”之间可能已经写入文件，扫描用于弥补这段窗口。软链接、挂载边界是否跟随应明确配置策略，而不是默认认为路径树等于 inode 树。
Go 落地思路： 维护 wd -> 目录路径 映射和被监控目录集合；扫描时限制根目录、深度与目录总数，并记录 watch 安装失败数。超过 max_user_watches 时不得把“部分覆盖”展示成“监控正常”。
2. 发布时使用原子重命名，应该观察哪些事件？
简洁答案： 同目录内临时文件重命名通常在目录 watch 上表现为 IN_MOVED_FROM 和 IN_MOVED_TO；从监控范围外移入时，可能只看到 IN_MOVED_TO。只监听 IN_MODIFY 会漏掉这种替换。
关键知识点： cookie 可关联同一次重命名的两端，但配对事件未必都在监控范围内。目录事件的 name 是相对被监听目录的名字，不能仅凭文件名归因到写入者。文件自身的 watch 绑定旧 inode；替换路径后应重新检查目标路径及 watch。
Go 落地思路： 对 IN_CLOSE_WRITE、IN_MOVED_TO、IN_CREATE 和 IN_ATTRIB 触发有界的元数据/哈希检查；对于删除或移出更新基线。用 cookie 做短时关联，超时后允许单边事件，避免无限等待。
3. 出现 IN_Q_OVERFLOW 后还能相信事件流吗？
简洁答案： 不能把溢出前后的事件拼成一份完整历史。溢出通知表示有事件丢失，但不告诉你丢了哪些文件、多少次操作或谁做的。
关键知识点： IN_Q_OVERFLOW 的 wd 为 -1，属于整个 inotify 实例，而非某个目录。溢出时保留已知状态供审计，但必须标记时间窗为不完整。加大队列上限只能减小概率，不能取代恢复机制。
Go 落地思路： 将覆盖状态标为 degraded，按根目录调度全量扫描，把当前快照与持久化基线对比；扫描完成前不能宣称“无变化”。记录溢出次数、扫描耗时和仍未恢复的根目录。
4. 全量扫描和实时事件并发时，怎样避免再次漏掉文件？
简洁答案： 先确保目录 watch 已安装，在扫描期间继续读取并暂存事件，扫描完成后处理扫描期间事件涉及的路径，再恢复正常状态。扫描和重放不能消除所有竞态，但可以把无法证明完整的窗口明确暴露出来。
关键知识点： 对象可能在读取元数据与哈希之间被替换；对敏感文件应打开 fd 后用 fstat 对照并在必要时重试。扫描期间事件缓冲也必须有上限；再次溢出或缓冲满时重新标记降级并安排下一轮对账。Agent 重启后的空窗同样需要启动扫描。
Go 落地思路： 一个读事件 goroutine 持续消费 fd，扫描任务按根目录串行或限并发执行；事件只标记待重查的相对路径，不无界保存原始事件。基线版本与扫描完成时间一起提交；无法完成扫描则保留上一次可信版本及覆盖缺口。
5. IN_IGNORED、IN_DELETE_SELF 和 watch descriptor 复用怎么处理？
简洁答案： 被监听 inode 删除、卸载或显式移除 watch 时可能收到 IN_IGNORED；IN_DELETE_SELF 表示对象自身被删除。这些事件之后不能继续假定原 watch 代表原路径，整数 wd 以后也可能被复用。
关键知识点： 路径可被新 inode 占据，旧 inode 的 watch 不会自动跟随新路径。只用 wd 作为永久身份容易把滞留事件错误归到新目录；重建 watch 时要核实路径和 inode。覆盖挂载也可能使原 watch 留在旧对象上，却看不到路径的新视图。
Go 落地思路： 移除旧映射后重新 stat 路径、安装 watch 并扫描；同一批 read 返回的事件应先按当时映射解释，再更新映射。对挂载变化另做周期覆盖核验，不把 watch 数量当作覆盖证明。
6. 如何避免把文件变化直接判成“Web 后门已落地”？
简洁答案： inotify 证明监控到的目录项或 inode 发生过变化，通常不提供写入者 PID，也不能单独证明文件内容恶意或被执行。
关键知识点： 需要结合内容特征、文件类型、Web 根目录、发布窗口以及 audit/eBPF 的进程证据。批量发布和攻击者落地都可能产生大量重命名；误报治理不应永久忽略整个目录。发生溢出时，“未观测到变化”不能作为无攻击证据。
Go 落地思路： 告警拆成 file_change_observed、content_suspicious、writer_attributed、executed 等独立事实，附带 coverage=complete|degraded|unknown 与证据来源；只有满足足够证据时提升严重度。
7. 线上频繁溢出或 watch 安装失败，如何排查资源问题？
简洁答案： 先区分“目录数超限”“实例/文件描述符限制”“消费速度不够”，不要盲目提高所有 sysctl。
关键知识点： /proc/sys/fs/inotify/max_user_watches、max_user_instances 和 max_queued_events 控制不同资源；watch 还会占用内核内存。慢速哈希或同步网络上报不应阻塞事件读取。对高变动缓存目录可用明确的低优先级策略，但要报告不覆盖范围。
Go 落地思路： 分离读取、去重调度和文件检查；记录事件读取延迟、失败 errno、活跃 watch 数、溢出次数与扫描积压。只在实测内存/CPU 和覆盖目标后调整上限，重启后确认实际生效。
学习要点
| 概念 | 面试时要说清的边界 |
|---|---|
| 目录 watch | 非递归；路径替换与挂载变化可能改变可见对象 |
| 重命名 | cookie 可配对，但两端不一定都可见 |
| 队列溢出 | 不能还原丢失事件；需要降级标记和全量对账 |
| 快照 | 能发现扫描时仍存在的差异，无法复原空窗内创建又删除的文件 |
| 归因 | inotify 不是写入进程审计；需要其他采集源补充 |
小练习 / 复盘题
- 画出启动扫描、新目录创建、安装 watch、扫描新目录的时序图；标出两个竞态窗口及补救方式。
- 设计一组隔离测试：写临时文件后重命名、监控范围外移入、删除后重建目录、超过 watch 限额；分别记录预期事件和最终快照。
- 模拟
IN_Q_OVERFLOW后“恶意文件创建又删除”：说明快照能发现什么、不能证明什么，以及如何向客户表述覆盖缺口。 - 给出三个指标和一个告警，判断 Agent 是“无文件变化”还是“采集失明”。