Shared Memory Access Problem

[Bob Furber]

First of all, you are right. This problem has nothing to do with GCC. It 
started out as a libc or librtl problem, which is probably handled more 
appropriately on another list or forum. Now it has become an obscure 
Linux problem. Not sure where to turn to.

Having said this, thanks for the tip about umask(). This allowed me to 
change the access privileges to the shared memory.

Regrettably, my first experiment was with unmask(777) which did horrible 
things. Now mmap() throws a "Permission denied" error, even though 
/dev/shm/shared has 777 privileges. It appears to be from detached 
memory blocks that do ipcrm cannot remove:

ts7500:~# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch status
0x75000000 0          root      0          4096       8

My guess is the segment cannot be released because it is attached to 8 
processes and I cannot find them to kill them. Nor do they release the 
segment on terminating. I have tried rebooting and depowering + 
rebooting, all to no avail. The controller always comes back with 
nattach = 8.

Thanks,

RF


On 12-09-11 10:12 AM, Jonathan Wakely wrote:
> On 11 September 2012 17:23, Bob Furber wrote:
>> On 12-09-07 04:08 PM, Jonathan Wakely wrote:
>>> On 8 September 2012 00:03, Bob Furber wrote:
>>>>
>>>> Why is the client capable of accessing shared memory when executed by
>>>> root
>>>> and not able to, when executed by a user?
>>>
>>> This doesn't sound like it has anything to do with GCC.
>>
>> After a lot of experimentation, I think the problem lies in shm_open().
> So nothing to do with GCC then.
>
>> The following code generates a /dev/shm/shared with -rw-r--r-- access
>> privileges, making it inaccessible to others, even though the mode is set to
>> rw-rw-rw-:
>>
>> shmfd = shm_open( shm_name,     // shared memory block with this "/name"
>>                    O_CREAT,      // Create if not already there
>>                    0666 );       // with these access privileges
> It sounds like your process has a umask of 0022.
>