Re: Posix shared memory - permission problems?
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com hi terry, derek, thanks very much for your replies. to answer both those questions: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Setting aside your use of the term "shared memory" :-), I notice that in your example: SharedMemID = shm_open(memname, O_CREAT | O_RDWR, 0x777); you pass "0x777" for the mode_t value; this lacks the S_IWUSR bit (0000200)--perhaps you intended to use "0777" instead? A failure due to this would match the errno value (EACCES) that you >report for the subsequent O_RDWR attempt... this won't be the problem. that was just mistyping in my e-mail. in my code i definitely use 0x0777 so that user, group and other all have read, write and execute access. i know that a lot of these permissions are unnecessary but i wanted to allow everything until i got closer to the cause. On Sep 19, 2007, at 8:32 AM, Tom O'Grady wrote: [creating read only shared memory using same name]: CLockMutex mutexSection(mutex); // mutex created using posix semaphore. SharedMemID = shm_open(memname, O_RDONLY, 0x777); // Create shared memory with read access. struct stat fstats; fstat(SharedMemID, &fstats); // check to see if the memory has been allocated and initialised // In this case, the size is already set and the permissions are set to 0x777. Therefore no truncation is required - I just map the memory: smptr = mmap( 0, size, PROT_READ, MAP_SHARED, SharedMemID, 0 ); I suspect that in your real code you are specifying O_CREAT in the O_RDNOLY case, and that is causing the mode to get rest on the shared memory object. If you're not sure if the shared memory exists, you should specify O_EXCL on the create, which will prevent it from being created if it already exists. again - in this test case i am definitely not specifiying O_CREAT when I open the memory for read only access. i only call shm_open with the O_CREAT flag in the first instance, when it's opened and created with read AND write permissions. even though i was under the impression that O_CREAT has no effect when the shared memory exists already, i decided not to call it in the second instance for the simplicity of this test. i'm going to try and strip out the semaphore-implemented mutex to see whether the test works fine then. if it does i'll report back as it might be of use to others. otherwise - i'd still appreciate any suggestions! thanks, tom This email sent to site_archiver@lists.apple.com
participants (1)
-
Tom O'Grady