macOS沙盒进程权限隔离由内核实时拦截裁决，非依赖用户身份或文件权限：默认仅限访问自身容器目录，越界操作返回EPERM；权限取决于entitlements声明与TCC动态授权，用户可随时撤回且立即生效。
macOS 沙盒环境下的进程权限隔离，不是靠“给应用设个密码”实现的，而是从内核启动那一刻起，就为每个进程划出专属边界——它能做什么、能碰哪些文件、能和谁说话，全由系统在运行时实时拦截并裁决。
沙盒是独立于用户身份的执行约束
即使你用管理员账户双击打开一个 App，它也不会自动继承你的全部权限。系统会按该 App 的签名和 entitlements 文件，为其创建一个受限的执行上下文：
- 它默认只能读写自己沙盒容器内的路径（如
~/Library/Containers/com.example.app） - 访问
~/Documents或~/Desktop必须弹窗让用户选中文件或授予权限，不能靠 chmod 或 chown 绕过 - 以 root 身份运行的进程也不自动豁免沙盒——除非它明确声明且通过 Apple 审核（如部分系统工具）
权限由 entitlements 声明，非文件系统权限决定
一个 App 是否能联网、调用摄像头、监听剪贴板，不取决于它所属用户的 group 或 umask，而取决于它的 entitlements 文件是否包含对应 key：
-
com.apple.security.network.client→ 允许发起网络连接 -
com.apple.security.files.user-selected.read-write→ 支持通过 NSOpenPanel 授权后读写任意用户文件 -
com.apple.security.automation.apple-events→ 请求自动化权限（需用户手动在「系统设置 → 隐私与安全性 → 自动化」中勾选）
这些声明在签名时固化，运行时由内核策略引擎校验；改文件权限或切换用户身份，都无法激活未声明的能力。
越界操作被内核直接拒绝，错误码明确区分
当沙盒进程尝试违规操作，系统返回的不是模糊的 EACCES（权限不足），而是清晰的 EPERM（操作被策略禁止）：
- 调用
open("/etc/shadow", O_RDONLY)→ 返回EPERM，表示沙盒策略拦截 - 尝试
connect()到未授权端口 → 同样是EPERM，而非连接超时或拒绝 - 用 XPC 向未声明 service bundle ID 的进程发消息 → 被
launchd拒绝，不进入目标进程地址空间
这种设计让开发者和调试者能快速定位是“权限没申”，还是“路径写错了”。
用户控制权始终在前台，TCC 动态生效
沙盒本身不替你做决定，所有敏感能力都需显式授权，且可随时撤回：
- 「完全磁盘访问」权限只开放公共目录（
~/Documents、~/Downloads等），不打通沙盒容器 - 辅助功能权限仅对具体进程生效（如 iTerm2 和 Terminal 是两个独立条目）
- 撤销某项权限后，对应 API 调用立即失败，无需重启 App
系统不会因升级或重装而重置这些选择，TCC 数据库存储在 /Library/Application Support/com.apple.TCC/TCC.db，受 FileVault 加密保护。
