macos文件系统权限与进程权限是两套独立但协同的分层安全机制：前者基于posix/acl控制用户对文件的访问，后者通过沙盒机制限制应用行为；二者先后拦截，非简单叠加。
macOS 的文件系统权限和进程权限是两套独立但协同工作的安全机制，分别控制“谁可以访问什么文件”和“某个程序能做什么”。它们不是叠加关系，而是分层拦截：文件系统权限先拦一次，进程权限（尤其是沙盒）再拦一次。理解这种双层隔离，才能真正管住数据和行为。
文件系统权限：POSIX 与 ACL 共同构成访问入口闸门
macOS 底层沿用 Unix 的 POSIX 权限模型（user/group/others + rwx），决定一个用户能否打开、修改或执行某个文件或目录。比如 chmod 700 后，只有所有者能读写执行，组和其他人完全被拒之门外。
ACL（访问控制列表）则在此基础上提供细粒度补充，允许为特定用户或组单独授权，例如：chmod +a "allow:john:read" /secret/file。ACL 优先级高于 POSIX，但仅作用于文件系统层面——它不阻止进程本身的行为，只限制对磁盘上资源的直接访问。
关键点：
- 文件系统权限由内核在 open()、stat() 等系统调用时实时检查，返回
EACCES表示被拒绝 - 它不区分“是哪个应用在访问”，只看当前执行用户的 UID/GID
- 即使一个进程以你的身份运行，它仍受你账户的文件权限约束；但若进程以 root 运行，就可能绕过大部分文件权限（除非有更高级防护）
进程权限：沙盒机制定义应用能力边界
进程权限的核心是沙盒（Sandbox），它不依赖用户身份，而是基于应用签名和 entitlements 文件声明的能力。一个被沙盒化的 App 即使以你身份运行，也无法访问未声明的路径（如 /etc）、网络端口或其它进程内存，哪怕你的账户对该路径有 full control。
例如，一个图片编辑器即使拥有你账户的全部文件权限，若没声明 com.apple.security.files.user-selected.read-write，它连你双击选中的照片都打不开——系统会弹窗让你手动授权。
关键点：
- 沙盒在进程启动时加载策略，由内核的 sandboxd 和 XNU 内核模块共同执行
- 它拦截的是系统调用（如 connect()、mach_port_mod_refs()），而非单纯路径检查
- 沙盒策略可精细到服务名（如
com.apple.accounts）、Mach 消息类型或文件操作动词（file-write-data）
两层隔离如何协同与冲突
当两者同时生效时，并非“取交集”，而是“先后拦截”。典型流程如下：
- 用户双击启动 App → 系统验证签名并加载 entitlements → 启动沙盒环境
- App 尝试读取
~/Documents/report.pdf - 内核先查沙盒策略：是否允许该 App 访问用户文档？若否，直接拒绝，不进入文件权限检查
- 若沙盒允许，则继续检查文件系统权限：当前用户是否有读权限？若否，返回
EACCES - 若两者都通过，才真正完成 open()
常见误区：
- 给文件设
700并不能阻止沙盒化 App 访问——只要它声明了对应 entitlements，系统就会代为授权 - 关闭沙盒（如开发调试时）会让 App 获得用户账户的全部文件权限，此时文件系统权限成为唯一防线
- ACL 条目对沙盒进程无效，除非 entitlements 显式允许且路径在沙盒白名单内
绕过风险与加固建议
真正的风险点往往出现在两层隔离的缝隙中：比如临时例外权限（temporary-exception）、未签名工具、或通过 AppleScript/automator 间接调用高权限进程。
实用加固方式：
- 对敏感文件夹，同时使用
chmod -R 700+ “显示简介”中移除everyone权限 + 启用“锁定” - 开发 App 时避免
com.apple.security.temporary-exception.*类 entitlements，改用用户主动选择（user-selected）模式 - 禁用不必要的辅助功能权限（如屏幕录制、输入监控），这些不受沙盒限制，却能绕过文件/进程隔离
- 对跨账户共享场景，优先用
/Users/Shared+ 粘滞位（chmod +t），而非放宽个人目录权限
