Reasons a user might not be able to open a shared memory object on Linux systems

Question

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.

Answer 1

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.