用户可能无法在Linux系统上打开共享内存对象的原因 [英] Reasons a user might not be able to open a shared memory object on Linux systems

问题描述

我对我支持的应用程序有一些麻烦，由于各种恼人的原因，分叉工作进程来处理一些任务。这些进程使用共享内存空间传达状态和有时结果。我使用boost interprocess库来完成这个（使用shared_memory_object和mapped_region类型）。

在其中一个系统部署到我们有非常有限的访问，那个系统很难。有一个完整的过程，只是为了得到一个新版本的软件安装。但是在这个目标上，我们遇到了一个问题，一个用户尝试启动应用程序，这是正常的，而另一个用似乎完全相同的凭据，组联属关系等无法创建共享内存对象。提升错误是权限被拒绝。对于任何尝试创建共享内存对象的尝试，即使名称尚不存在，也会返回此信息。

我只能在我的通过以root身份启动应用程序来结束，因此内存空间是使用受限权限创建的，然后作为非root用户重新运行，这会产生相同的权限问题。这个我能够通过调用set_unrestricted例程在权限对象上修复这里。但是，这不是什么发生在这个远程系统上，因为用户都是root，一个用户不能创建任何命名的内存对象，甚至是新的。

我的问题是其他原因可能会阻止一个用户打开共享内存对象？我只找到了根/非根限制，但我还没有找到任何其他可能的解释。

这是使用boost 1.55 interprocess库

$ p

ul>

/ dev / shm权限（也可以使用/ dev / direntry上的+ x）

librt.so

ulimit有效

输出 id

SELinux配置（getenforce，setenforce 0）

AppArmor（在此类系统上不太可能是罪魁祸首， b $ b

此外，并不是所有的内核都有SHM支持编译，但这不会立即出现问题。

I'm having some trouble with an application I'm supporting that, for various annoying reasons, forks worker processes to handle some tasks. These processes communicate status and sometimes results using a shared memory space. I'm using the boost interprocess library to accomplish this (using shared_memory_object and mapped_region types).

On one of the systems deployed to we have extremely limited access, making debugging on that system difficult. There's a whole process just to get a new version of the software installed. But on this target we're running into the issue where one user, attempting to launch the application, is able to do so just fine while another, with seemingly identical credentials, group affiliations, etc, is unable to create the shared memory object. The boost error is "permission denied". This is returned for any attempt to create a shared memory object, even if the name doesn't already exist.

I've only been able to reproduce this problem on my end by launching the application as root so the memory space is created with restricted privileges then re-running as a non-root user, which gives the same permission issue. This I was able to fix by calling the set_unrestricted routine on the permissions object as mentioned here. However, this is not what's occurring on this remote system as neither user is root and one user cannot make any named memory object, even new ones.

My question then is what other reasons might be preventing one user from opening shared memory objects? I've only found mention of the root / non-root restrictions but I've not been able to find any other possible explanations.

This is using boost 1.55 interprocess library to create a shared memory object on a Linux system.

解决方案

Check

• /dev/shm permissions (also +x on /dev/ direntry)
• availability/accessibility of librt.so
• ulimit in effect
• output of id for primary as well as secondary groups
• SELinux configuration (getenforce, setenforce 0)
• AppArmor (unlikely culprit on such a system, but still)

Also, not all kernels have SHM support compiled in, but that doesn't immediately seem to be the problem here.

这篇关于用户可能无法在Linux系统上打开共享内存对象的原因的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！