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