On 06/07/2010 16:35, Matt Cupp wrote:

From: http://groups.google.com/group/boost-list/browse_thread/thread/fc728b9d416c6...

...

Interprocess has this embarrasing permission limitations, but I still don't know how to fix it.

Does the permissions limitation apply to Linux (CentOS) and shared mutexes or segments created by other users or root?

I have a mutex in the /dev/shm folder created by another user with these permissions (from ls -l): -rwxr-xr-x 1 webers users 160 Jul 1 15:24 Lookup_Mutex

In theory shm_open is called with these persissions: www.boost.org/boost/interprocess/shared_memory_object.hpp m_handle = shm_open(m_filename.c_str(), oflag, S_IRWXO | S_IRWXG | S_IRWXU); But shm_open final permissions are dependent, just like open(), on umask(). Since by default umask() is 022, then you got that. Change umask() (a thread-unsafe and global function, by the way), so that you can get all the permissions. From posix: "The permission bits of the shared memory object shall be set to the value of the mode argument except those set in the file mode creation mask of the process. When bits in mode other than the file permission bits are set, the effect is unspecified. The mode argument does not affect whether the shared memory object is opened for reading, for writing, or for both." You can use fchmod after shm_open to change effectively permissions after the object is created: #include <sys/stat.h> int fchmod(int fildes, mode_t mode); I will probably add this fchmod call in the future. Hope this helps, Ion