Date: Sat, 12 Aug 2017 12:03:09 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Yuri <yuri@rawbw.com> Cc: Freebsd hackers list <freebsd-hackers@FreeBSD.org> Subject: Re: How can the shared memory object be undeletable when all shared memory segments belong to the same user? Message-ID: <20170812090308.GH1700@kib.kiev.ua> In-Reply-To: <b959b884-c362-5d93-39bb-6d9c9fd4f6bf@rawbw.com> References: <b959b884-c362-5d93-39bb-6d9c9fd4f6bf@rawbw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170812090308.GH1700>