界面说不行，不代表系统真的不行

今天 HN 上最值得认真看的文章之一，是一篇很典型、也很容易被忽视的系统安全文章。它讨论的不是传统意义上的高危漏洞，也不是那种需要复杂利用链的攻击技巧，而是一件更日常、也更麻烦的事：你在 macOS 的 Privacy & Security 里看到某个应用对 Documents 的访问已经被关闭了，但这件事未必真的意味着它失去了访问能力。

这类问题之所以值得写，不只是因为它牵涉到某个具体平台，而是因为它触到了一个更普遍的系统设计问题：用户看到的控制界面，到底是在真实表达系统状态，还是只是在表达"系统本来希望如此"。这两者差得很远。

原文作者做了一个很干净的实验。先让应用通过常规 TCC 同意流程获取 Documents 权限，再在系统设置里把这个权限关掉。到这里，一切都符合用户预期。接着，作者通过系统的 Open Panel 让用户"主动选择"Documents 文件夹。此后，应用又重新获得了对该目录的访问能力，而且更麻烦的是，Privacy & Security 里的 Files & Folders 仍然显示它对 Documents 是关闭状态。也就是说，界面说"禁止"，系统实际却还能"允许"。

嗯，这才是最危险的地方。不是单纯的"多给了一次权限"，而是"权限真实状态和可见状态分离了"。当用户无法再通过系统界面正确理解当前边界，控制权就变成了一种幻觉。安全设置最怕的从来不只是默认不安全，而是它让人误以为自己已经完成了控制。

从安全工程角度看，这件事暴露的并不是单一 bug，而是一种权限模型中的语义错位。TCC、sandbox、用户意图表达、文件系统附加属性、设置面板里的可见状态，这几层本来应该共同组成一套一致的授权与撤销机制。但在这个例子里，它们像是不同年代、不同团队设计出来的零件，被勉强拼在一起。授权能跨层生效，撤销却不能跨层撤销；实际能力发生了变化，界面却没有跟着更新。于是系统内部"是真的"，用户界面"是假的"。

这类问题的教训其实不只适用于 macOS。很多现代权限系统都在做同一件事：试图在严格访问控制和用户便利性之间找平衡。只要系统允许"按用户意图临时放行"，就一定会遇到一个问题：这种放行到底是一次性的、会话级的、对象级的，还是会留下持久副作用。更重要的是，用户有没有办法从一个统一界面里看见并撤销这些副作用。如果没有，那么这个"方便"最后常常会演变成不可解释的状态污染。

这也解释了为什么很多安全问题，在工程师看来可能只是实现细节，在用户看来却是信任崩塌。因为大多数人并不理解 TCC、sandboxd 或 xattr 是怎么互相作用的，他们只会理解一件事：我已经关掉了，为什么它还能读。这个问题一旦无法用直觉解释，用户就会自然得出结论——系统设置不可信。

我觉得这篇文章最有价值的地方，是它提醒我们不要把"用户可见的权限开关"自动等同于"系统唯一真实的授权源"。现实里，权限常常是多源的：显式授权、隐式授权、对象级 capability、历史缓存、会话继承、文件选择器授予、系统服务代持，甚至某些为了兼容性保留下来的旧路径。真正稳健的设计，不是让这些机制同时存在，而是确保它们能被统一解释、统一展示、统一撤销。

如果把这个问题延伸到更广泛的软件设计里，结论也很实用。第一，不要轻信 UI 上的"已关闭""已禁用""未授权"之类字样，尤其在复杂系统里，它们常常只是某一层状态。第二，如果你在设计权限系统，撤销路径的重要性不低于授权路径。很多产品把"如何允许"设计得很顺滑，却把"如何真正收回"做得像巫术。第三，凡是允许"按用户操作自动放行"的系统，都应该非常谨慎地定义持久性边界，否则临时便利很容易变成长期漏洞。

从用户角度说，这件事并不会立刻改变大多数人的使用方式，但它会改变一个更基础的判断：安全控制面板不是神谕，它只是系统状态的一种投影。而投影，是可能失真的。

真正可靠的系统，不是给你很多开关，而是这些开关真的对应到底层世界。否则你看到的不是控制，而只是安慰。