用户可能无法在 Linux 系统上打开共享内存对象的原因

Posted 2023-02-16

【中文标题】用户可能无法在 Linux 系统上打开共享内存对象的原因

【英文标题】：Reasons a user might not be able to open a shared memory object on Linux systems

【发布时间】：2015-06-15 16:51:54

【问题描述】：

我在支持某个应用程序时遇到了一些问题，由于各种烦人的原因，它派生了工作进程来处理某些任务。这些进程使用共享内存空间来传达状态和结果。我正在使用 boost 进程间库来完成此任务（使用 shared_memory_object 和 mapped_region 类型）。

在部署到其中的一个系统上，我们的访问权限极其有限，因此很难在该系统上进行调试。有一个完整的过程只是为了安装新版本的软件。但是在这个目标上，我们遇到了这样一个问题：一个用户尝试启动应用程序时能够正常启动，而另一个用户，具有看似相同的凭据、组从属关系等，无法创建共享内存对象。提升错误是“权限被拒绝”。任何尝试创建共享内存对象时都会返回此值，即使名称尚不存在。

我只能通过以 root 身份启动应用程序来重现此问题，因此使用受限权限创建内存空间，然后以非 root 用户身份重新运行，这会产生相同的权限问题。我可以通过在here 中提到的权限对象上调用 set_unrestricted 例程来解决此问题。但是，这不是在这个远程系统上发生的事情，因为两个用户都不是 root，并且一个用户不能创建任何命名的内存对象，甚至是新的。

那么我的问题是，还有哪些其他原因可能会阻止用户打开共享内存对象？我只发现提到了根/非根限制，但我找不到任何其他可能的解释。

这是使用 boost 1.55 进程间库在 Linux 系统上创建共享内存对象。

【问题讨论】：

perror() 究竟说明了什么？

在我更新远程系统上的软件之前，我无法回答这个问题，不幸的是，这需要与他们的系统管理员进行一些交互。不幸的是，这种故障模式没有得到正确处理，所以我唯一的输出是断言抛出的 boost 错误消息。

【参考方案1】：

检查

/dev/shm 权限（在 /dev/direntry 上也是 +x） librt.so 的可用性/可访问性 ulimit 生效 主要和次要组的id 输出 SELinux 配置（getenforce、setenforce 0） AppArmor（不太可能是此类系统的罪魁祸首，但仍然如此）

此外，并非所有内核都编译了 SHM 支持，但这似乎并不是问题所在。

【讨论】：

我可能可以排除大多数这些情况（除了我不熟悉并且必须研究的 ulimit），因为另一个用户可以使用与用户相同的组和权限很好地执行操作谁无法执行该操作。在这种情况下，我认为没有使用 SELinux 或 AppArmor。

重点是仔细检查这些。显然我并不是说我知道你的系统出了什么问题。但请不要检查“我没有在使用它”:)