macos应用安装权限变更是gatekeeper、sip、沙盒与用户授权协同作用的结果：gatekeeper校验签名与公证决定能否启动；.pkg或拖入/applications需管理员密码因sip保护关键路径；沙盒限制运行时访问范围；更新复用对应权限逻辑。
macOS 应用安装过程中的权限变更，本质是系统在多个安全层之间动态协商访问权的过程。它不是简单的“给不给管理员密码”，而是 Gatekeeper 验证来源、SIP 限制写入路径、沙盒机制约束运行时行为、用户授权决定文件访问范围的协同结果。
Gatekeeper 先验检查：决定“能不能启动”
安装前或首次启动时，Gatekeeper 就已介入：
- 检查应用是否带有有效的 Apple 签名（Developer ID）且已完成公证（Notarization），否则直接拦截并提示“来自身份不明的开发者”
- 即使你手动拖进 /Applications，Gatekeeper 仍会在双击时校验；若签名失效或未公证，会返回
spctl --assess的 rejected 结果 - 临时绕过（右键→“打开”→“仍要打开”）仅解除本次执行限制，不改变签名状态，也不影响后续更新或后台行为
安装器执行时的权限提升：决定“写到哪、写什么”
真正触发权限变更的是安装动作本身：
- .pkg 安装包默认需输入管理员密码——因为其脚本常向 /usr/local、/Library 或 /Applications 写入，这些路径受 SIP 保护，普通用户无权操作
- 拖放式 .app 文件虽不调用安装器，但写入全局 /Applications 仍需管理员授权（系统会弹出权限请求）
- 若改用 ~/Applications 或 ~/Library/Application Support，则完全避开 SIP 和管理员密码，因用户主目录天然可写
沙盒与运行时权限：决定“装完之后能做什么”
安装完成≠权限落地，运行时还有第二轮约束：
- Mac App Store 下载的应用默认启用沙盒，只能访问自身容器目录（~/Library/Containers/xxx）和用户显式授权的路径（如通过 NSOpenPanel 选择的文件夹）
- 若把沙盒应用从 /Applications 移到桌面或自定义路径，其容器路径映射会失效，导致偏好设置丢失、文档库无法加载、旁白等辅助功能异常
- 非沙盒应用（如官网下载的 Chrome、VS Code）虽不受容器限制，但仍受 SIP 保护——无法修改 /System 或 /bin，也无权读取其他应用的沙盒数据
自动更新带来的隐性权限变化
更新不是静默的，它复用安装时的权限逻辑：
- App Store 应用更新以当前用户身份运行，只更新该用户账户下的数据，无需再次输密码
- 系统级更新（如 macOS 15.5）必须由管理员触发，重启后以 root 权限写入 /System 和 /usr，日志明确记录在 /var/log/install.log
- 第三方应用自更新（如 Slack、Zoom）通常走用户级路径（~/Library/Application Support），但若更新涉及内核扩展或系统服务，则会弹出权限请求
