linux-kernel - Re: [PATCH] Don't set sempid in semctl syscall.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 28 Feb 2016 20:16:49 +0100
From:	Michael Kerrisk <mtk.manpages@...il.com>
To:	PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>
Cc:	Manfred Spraul <manfred@...orfullife.com>,
	Andrew Morton <akpm@...ux-foundation.org>, herton@...hat.com,
	penguin-kernel@...ove.sakura.ne.jp, rientjes@...gle.com,
	Davidlohr Bueso <dave@...olabs.net>, joe@...ches.com,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Don't set sempid in semctl syscall.

On Sat, Feb 27, 2016 at 9:42 AM, PrasannaKumar Muralidharan
<prasannatsmkumar@...il.com> wrote:
> Agreed. Is it better to change the man page and document the behaviour?

Requoting text I just added to the Bugzilla report to explain why the
right approach seems to be to document, rather than change this
behavior:

So, given that there is implementation variation that probably
predates POSIX.1 (I'm assuming that the OpenSolaris behavior has an
ancestry that stretches way back), I'd argue that the fault here lies
with POSIX, inasmuch as it failed to capture the full variation in
existing implementation behavior. (The BSD implementations of System V
IPC were post facto.) Generally POSIX.1 does not try to prescribe away
existing implementation behavior, but instead creates a loose spec,
not that an implementation "may do such and such".

I've added the following text to the semctl(2) man page:

   The sempid value
       POSIX.1 defines sempid as the "process ID of [the] last  opera‐
       tion"  on  a semaphore, and explicitly notes that this value is
       set by a successful semop(2) call, with the implication that no
       other interface affects the sempid value.

       While some implementations conform to the behavior specified in
       POSIX.1, others do not.  (The fault  here  probably  lies  with
       POSIX.1  inasmuch as it likely failed to capture the full range
       of existing implementation behaviors.)  Various other implemen‐
       tations also update sempid for the other operations that update
       the value of a semaphore: the SETVAL and SETALL operations,  as
       well as the semaphore adjustments performed on process termina‐
       tion as a consequence of the use  of  the  SEM_UNDO  flag  (see
       semop(2)).

       Linux  also  updates sempid for SETVAL operations and semaphore
       adjustments.  However, somewhat  inconsistently,  it  does  not
       update sempid for SETALL operations.  While the SETALL behavior
       might be viewed as a bug, the behavior is longstanding, and  is
       probably unlikely to change.

Cheers,

Michael

-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/