将低频任务纳入服务权限回归测试

一个服务重启成功、首页能打开，并不等于这次权限收紧是安全的。真正容易出问题的地方，往往不是高频请求路径，而是那些一周甚至一个月才触发一次的定时备份、日志轮转、证书更新和故障恢复流程。它们平时不参与日常流量，也不会在 systemctl status 里留下明显的异常，却恰恰最依赖那些看起来“用不上”的权限。

低频任务的麻烦在于反馈周期太长。收窄 RestrictAddressFamilies 之后，HTTP 出入站照常工作，但备份脚本可能改用另一种地址族的套接字与本地组件通信，直到下一次备份窗口才暴露。PrivateDevices、ProtectKernelTunables、ProtectKernelModules 也是同理：主流程不需要直接触碰设备节点、内核参数或模块加载，但某个只在轮转时被调用的辅助进程可能需要。日志里没有出现相关访问记录，不足以证明这项能力可以关闭，因为低频路径本来就不会频繁出现在日志中。

因此回归测试的范围要按职责划分，而不是按调用频率划分。先用 systemctl cat 和 systemctl show 盘点服务的运行身份、工作目录与实际属性值，再把每一项候选限制对应到具体业务路径：登录、上传落盘、队列与计划任务、日志持续写入、备份生成与可读性。判断标准是“这项能力由谁、在什么业务路径上使用”，而不是“目前运行是否正常”。对纯后台服务，验证方式应当是主动触发一次真实任务并检查结果，备份要能生成且能读回，轮转要能完整走完。

执行时仍要保持一次只改一项的纪律。把限制写入独立的覆盖文件，daemon-reload 后重启服务，确认覆盖项已生效，再从业务入口而非进程状态验证。若重启失败或核心路径异常，先移除本次覆盖文件、重新加载并重启，重测刚才失败的路径，确认恢复后再定位原因，不要在同一次测试里叠加第二项限制。

复盘记录建议按“所需资源—验证路径—限制结果—保留或放弃理由”逐条落地。一份完整的权限回归清单，衡量标准不是主流程跑通了几次，而是低频任务是否被真实触发过、回退步骤是否走通过。缺了这一段，收紧权限就只是把风险推迟到下一个备份窗口。