0

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.

Community
  • 1
  • 1
Anthony
  • 2,256
  • 2
  • 20
  • 36
  • What does `perror()` tell actually? – πάντα ῥεῖ Jun 15 '15 at 16:53
  • That's a question that I won't be able to answer until I update the the software on the remote system, which unfortunately takes some interaction with their sysadmin. Unfortunately this failure mode wasn't being properly handled so the only output I have is the boost error message that's thrown by the assertion. – Anthony Jun 15 '15 at 16:58

1 Answers1

2

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.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • I can probably rule out most of these cases (except ulimit which I'm unfamiliar with and will have to research) because another user can perform the action just fine with the same groups and privileges as the user who is unable to perform the action. In this case I don't think SELinux or AppArmor is in use. – Anthony Jun 15 '15 at 18:38
  • 1
    The point is to double check these. Obviously I'm not claiming I know what's wrong on your system. But do check more than "I don't it's in use ":) – sehe Jun 15 '15 at 19:28