Re: sem_init: pshared=0 difference between Linux and NetBSD

[Greg Troxel <gdt%lexort.com@localhost>]

Valery Ushakov <uwe%stderr.spb.ru@localhost> writes:

>> I think the NetBSD behavior is a bug.
>
> Well, it would be nice to get a standalone test case to begin with.

Sure.  Perhaps create a non-shared, fork, and then have the child and
parent use the sem to interact.

> But if we are into exgetics, I'd note that posix text makes a
> distinction.  Shared as a property of a semaphore, and the fact that a
> process can access it are not the same.  To summarize the relevant
> paragraph:
>
>   1: the [shared] semaphore is shared between processes;
>   2: in this case, any process that can access the semaphore sem
>   3: can use sem for performing sem_*() operations.
>
> A process can access a semaphore sem (2) that is _not_ shared (1,
> negated), but in that case it can _not_ (3, negated) use the semaphore
> operations.

Yes, it's a bit messy.  I'd argue any attempted access to the non-shared
semaphore by another process is an error.  If it's the defined call,
then I think the semaphone needs to be non-broken and the access
rejected.  If it's a memory write, we're into UB.

> The fix in libgpg-error moves around the time the post-syscall hook is
> called and I suspect gpg was (indirectly, b/c its hook was called at
> the wrong time) doing something like the above, i.e. "using
> operations" on a semaphore that it "has access to", but that is not
> really shared.

If so, seems totally fair upstream to fix to avoid erroneous accesses.