This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: For review: nptl(7) man page


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]