How can the shared memory object be undeletable when all shared memory segments belong to the same user?

[Konstantin Belousov]

On Fri, Aug 11, 2017 at 09:58:52PM -0700, Yuri wrote:
> I got this sequence of shm_* failures that I can't understand:
> 
>   16151 scsynth  CALL  shm_unlink(0x803fdb3e0)
>   16151 scsynth  NAMI  "/SuperColliderServer_57110"
>   16151 scsynth  RET   shm_unlink -1 errno 13 Permission denied
POSIX specifies that shm_unlink returns EACCES when
  Permission is denied to unlink the named shared memory object.

Rationale for the shm_open() explains that actual interpretation of EACCES
for shm_*(2) functions is implementation-defined.  FreeBSD requires the
caller euid to have read/write permissions to the shared memory segment
for the unlink to be allowed.


> ...
>   16151 scsynth  CALL 
> shm_open(0x803fdb3e0,0xa02<O_RDWR|O_CREAT|O_EXCL>,0644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH>)
>   16151 scsynth  NAMI  "/SuperColliderServer_57110"
>   16151 scsynth  RET   shm_open -1 errno 17 File exists
> ...
>   16151 scsynth  CALL 
> shm_open(0x803fdb3e0,0x2<O_RDWR>,0644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH>)
>   16151 scsynth  NAMI  "/SuperColliderServer_57110"
>   16151 scsynth  RET   shm_open -1 errno 13 Permission denied
> 
> 
> Deletion operation fails with EACCESS, creation operation fails with 
> EEXIST, opening operation fails with EACCESS again. So the object 
> exists, but this user can't delete or open it.
Which is consistent with the euid not having read/write permissions on
the segment.

> At the same time, 'ipcs 
> -m' shows that all active segments belong to the same user. Failures are 
> persistent with application restarts.
Why do you think that SysV IPC shared memory, which is displayed by
ipcs(8) tool, has any relations to the POSIX shared memory ?

> 
> 
> Only renaming of the shared memory object in the code or reboot helped.
Root should be able to unlink it.