Boost Interprocess：named_mutex的sem文件权限受限，如何设置宽松权限？

看起来你遇到了Boost Interprocess的一个常见坑——虽然你给named_mutex和其他共享对象设置了无限制权限，但它生成的sem.*附属文件没有继承正确的权限，导致其他用户无法访问。我来给你几个可行的解决办法：

1. 临时修改进程umask（最可靠的代码层面修复） #

Boost Interprocess在创建IPC文件时，会受到进程当前umask的影响——即使你设置了permissions::set_unrestricted()，umask会自动过滤掉部分权限位。解决办法是在创建同步对象前临时把umask设为0，创建完成后再恢复：

void createMemory(const int numBytes) {
    permissions perm;
    perm.set_unrestricted();

    segment.reset(new managed_shared_memory(open_or_create, memory_name, numBytes, 0, perm));

    // 保存当前umask，临时设置为0以确保权限不被过滤
    mode_t original_umask = umask(0000);
    try {
        mutex.reset(new named_mutex(open_or_create, mutex_name, perm));
        cond_empty.reset(new named_condition(open_or_create, cv_name, perm));
    } catch (...) {
        // 发生异常时也要恢复umask
        umask(original_umask);
        throw;
    }
    // 恢复原来的umask
    umask(original_umask);

    const ShmemAllocator alloc_inst(segment->get_segment_manager());
    vec = segment->find_or_construct<MyVector>(vector_name)(alloc_inst);
}

这一步能确保sem.mutex_name文件创建时拥有你期望的全权限，不会被系统默认umask砍掉写权限。

2. 显式指定权限位，增强兼容性 #

有些场景下set_unrestricted()的跨平台表现可能不一致，你可以同时显式设置权限掩码为0777（或0666，根据你是否需要执行权限），双重保险：

permissions perm;
perm.set_unrestricted();
perm.set_permissions(0777); // 让所有用户都有读、写、执行权限

3. 临时手动修复已有文件（应急方案） #

如果需要快速让第二个用户访问，第一个用户可以手动修改sem.*文件的权限：

chmod 666 /dev/shm/sem.mutex_name

注意路径可能因系统而异，有些发行版的IPC文件存在/run/shm下，你可以用find /dev/shm -name "sem.*"定位文件。但这只是临时解决，下次重启程序或重新创建mutex时还会出现问题。

4. 排查bashrc设置无效的原因 #

你在bashrc里设置umask没用，大概率是因为你的程序不是从交互式bash shell启动的——bashrc只对交互式会话生效，如果你的程序是通过脚本、服务或其他非交互式方式启动，不会加载bashrc，进程的umask还是系统默认值（通常是0022，会去掉其他用户的写权限）。

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