Shared Memory Access Problem

Shared Memory Access Problem

[Bob Furber]

I have 2 programs that communicate through shared memory that work fine 
when I have root privileges, but fail when I sign on as a user. The 
server program that creates the shared memory set read an write 
permissions to allow everyone to access this memory (rw-rw-rw-).

    ShmID = shmget(ShmKEY, sizeof(struct Memory), IPC_CREAT | 0666);


Likewise, the client program, which is started after the server, creates 
the shared memory with rw-rw-rw- permissions.

    ShmID = shmget(ShmKEY, sizeof(struct Memory), 0666);

But, when I run the client program without root privileges,shmget() 
returns -1 and errno = 2 which supposedly means "File/Directory not found".

Why is the client capable of accessing shared memory when executed by 
root and not able to, when executed by a user?

I should mention that both the server and client executables have been 
chmoded to 777.

Re: Shared Memory Access Problem

[Jonathan Wakely]

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.

Re: Shared Memory Access Problem

[Bob Furber]

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().

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

Same for:

shmfd = shm_open( shm_name,	// shared memory block with this "/name"
		  O_CREAT,	// Create if not already there
		| O_RDWR,	// allow read and write access
		  S_IRWXU	// 00700 user has rwx privileges
		| S_IRWXG	// 00070 group has rwx privileges
		| S_IRWXO );	// 00007 others has rwx privileges


However, if this is followed by:

fchmod( shmfd,
	  O_CREAT	// Create if not already there
	| O_RDWR	// allow read and write access
	| S_IRWXU	// 00700 user (file owner) has rwx privileges
	| S_IRWXG	// 00070 group (file owner) has rwx privileges
	| S_IRWXO );	// 00007 others has rwx privileges

/dev/shm/shared ends up with rw-rw-rw- privileges (since it is not 
executable).

smget() was more difficult to troubleshoot because it does not produce a 
file descriptor and I could not find the corresponding file to check its 
access privileges.

RF

Re: Shared Memory Access Problem

[Jonathan Wakely]

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.

Re: 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.
>

Re: Shared Memory Access Problem

[Ángel González]

On 12/09/12 05:45, Bob Furber wrote:
> 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:
Did you read umask(2) ?

If you wanted to remove the umask(), you'd call umask(0). The umask is
used to specify the permissions that should *not* appear in the new file.


>
> 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
Killing the processes will not remove the segment (this interface is not
very consistent with other parts of the system). You can use ipcrm(1) to
delete the segment.

Rebooting the system does remove the existing shared memory segments. If
you're seeing it on reboot, some program run on boot is recreating it.

Re: Shared Memory Access Problem

[Ángel González]

On 11/09/12 18:23, Bob Furber wrote:
>
> smget() was more difficult to troubleshoot because it does not produce
> a file descriptor and I could not find the corresponding file to check
> its access privileges.
>
> RF
Run ipcs
It will give you an overview of shared memory, semaphores and message
queues, including their permissions.