On Wed, Aug 05, 2015 at 08:59:55PM +0200, Michael Kerrisk (man-pages) wrote: > >>> The semaphore example shows that there can be a disadvantage to > >>> guaranteeing 32/64b interoperability (specifically, the 64b code is more > >>> efficient). For mutex, I *currently* don't see a reason why we couldn't > >>> get away with just doing 32b stuff for the pshared case, but there's no > >>> guarantee that I can foresee all future needs either. > >>> > >>> Thus, if we would decide to guarantee 32/64b interoperability, we'd need > >>> to have at least strong use cases for that and a decent amount of > >>> confidence that making such a guarantee is unlikely to constrain the > >>> implementation in the future. > >> > >> Well, POSIX semaphores are supposed to be a replacement for System V > >> semaphores (and this extends to the rest of the POSIX IPC > >> primitives); right now they aren't. > > > > Only for some usage cases. As far as I can tell, POSIX semaphores are > > not intended to be required to be implemented as a kernel resource. > > That last is also true of SysV semaphores, surely? The grammar of my sentence was rather complicated and perhaps confusing. The intent was to say that SysV semaphores absolutely have to be a kernel resource, but POSIX semaphores don't (and aren't). > > They don't have permissions enforcement/safety against malicious > > processes, > > (I'm a little lost here. POSIX semaphores do have a permissions mask.) Yes, named semaphores have fs-like permissions, and of course you can do that with unnamed ones in named shared memory objects or files. However, as implemented in the real world, that provides no protection from a malicious process that _does_ have access permissions. With SysV semaphores, the worst a malicious process with access can do is wait/post the semaphore. With current implementations of POSIX semaphores, and other process-shared pthread sync objects, a malicious process that has access can utterly corrupt the state of the object. I am not sure of the extent of damage that can be achieved here, but there is not explicit effort to harden against it. > > backout on async process termination, etc. > > Actually, System V semaphores don't reliably have this either (see BUGS > in semop(2)). That's something of a design bug, but irrelevant to the reasonable usage which would be to post, not wait. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
