macOS环境下sem_open()在命令行正常、App内调用返回EPERM/EEXIST错误的问题咨询

两个测试场景的执行环境安全边界存在本质区别，代码逻辑完全一致的情况下出现调用结果分叉，核心原因是权限隔离规则不同：

• 命令行测试程序默认不启用应用沙盒，拥有对POSIX IPC全局命名空间的完整读写权限，可正常创建、删除、操作命名信号量。
• Xcode 12.4创建的原生macOS应用，默认自动开启 App Sandbox（应用沙盒） 能力：沙盒会将应用的所有资源访问限制在自身专属容器目录内，无额外授权时禁止访问系统全局路径下的POSIX IPC对象。
  对应到你遇到的两类报错：
  • 触发EPERM (errno=1)：沙盒直接拦截了应用对全局POSIX信号量存储路径的访问请求，不允许应用在沙盒范围外创建IPC对象。
  • 触发EEXIST (errno=17)：沙盒的路径映射规则下，历史残留的同名信号量被归属于其他权限域，应用自身执行的sem_unlink()没有权限删除这类跨域对象，导致后续带O_CREAT | O_EXCL标记的创建操作检测到同名对象存在，直接返回冲突错误。
    你观测到的返回值0xffff...是sem_open调用失败时固定返回的SEM_FAILED常量，不属于有效信号量句柄。

场景1：仅需进程内线程同步，无需跨进程共享 #

直接放弃命名信号量，改用内存中的POSIX无名信号量，这类对象完全运行在应用进程的内存空间内，不需要访问文件系统路径，可绕过所有沙盒权限拦截。
替换原有调用逻辑的示例：

// 替换原有的sem_unlink、sem_open调用
sem_t *sem = malloc(sizeof(sem_t));
// 参数说明：第二个参数为0表示线程共享，第三个参数为初始信号量值
sem_init(sem, 0, 1);

// 不再需要信号量时执行释放
sem_destroy(sem);
free(sem);

场景2：本地调试、非商店分发，需要使用跨进程命名信号量 #

可以直接移除应用的沙盒配置，让应用获得和命令行测试程序完全一致的执行权限：

1. 打开项目目标的配置页，进入Signing & Capabilities标签栏
2. 找到App Sandbox配置项，点击对应条目右侧的删除按钮移除该能力
3. 清理编译缓存后重新运行应用，即可正常调用sem_open创建全局命名信号量。

注意：关闭沙盒的应用无法通过Mac App Store的上架审核，仅适合本地开发、独立分发的非商店场景使用。

场景3：需要保留沙盒合规性，同时实现跨进程同步 #

沙盒环境下不支持直接操作全局命名信号量，需要改用系统默认允许的跨进程同步机制替代：

• 基于XPC服务传递同步状态，搭配Dispatch Semaphore实现进程间的互斥控制
• 基于NSFileCoordinator实现跨进程文件锁，完成多进程访问共享资源的互斥控制

内容的提问来源于stack exchange，提问作者user1418067