linux-kernel - Allow signaling a process by all its thread ids?

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-next>] [day] [month] [year] [list]

Message-Id: <1242944179.10298.11.camel@odie.local>
Date:	Fri, 22 May 2009 00:16:19 +0200
From:	Simon Holm Thøgersen <odie@...aau.dk>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Cc:	Michael Kerrisk <mtk.manpages@...glemail.com>,
	Jean-Paul Calderone <exarkun@...stedmatrix.com>
Subject: Allow signaling a process by all its thread ids?

There is a bug report at https://bugs.launchpad.net/bugs/341239 where
the question is asked. Should it be possible to signal a process with
kill(2) by passing any of the thread ids belong to the process as
argument to kill?

Current behaviour allows that but the reporter argues that it shouldn't
be allowed by the following argument:

"I'm no expert in interpreting POSIX.  A casual (but careful) reading of
POSIX 1003.1-2004 suggests that this isn't the intended behavior.  It is
implied in a few places, most notably the getpid[1] documentation, that
a process has only one PID (by use of the definite article when
referring to it - ie, "the process ID").  The kill function[2] operates
on "a process or a group of processes".  It sends a signal "to the
process whose process ID is equal to pid".  Combined with the previous
point, this suggests there should be only one process ID which can be
passed to kill to send a signal to a particular process.

It may be that POSIX is weakly worded enough that either allowing or
disallowing this behavior is valid.  I think that allowing it is a
violation of POSIX, but I can find no single, explicit, direct statement
in POSIX to back this up.

There is at least one other argument to disallow this behavior even if
it is not technically illegal.  Consider the traditional, widespread
convention of pid files.  This behavior drastically reduces their
utility, as it greatly increases the chance of PID collisions, a case in
which it is difficult to automatically (that is, without human
intervention) recognize that a pid file no longer corresponds to a
running process which created it.  This is the case in which I
encountered the behavior - when it repeatedly caused services not to
restart because they encountered a thread of another process and
misinterpreted it to mean the service was already running.

I hope this is convincing.  If not, what kind of argument would be?

[1]: http://www.opengroup.org/onlinepubs/009695399/functions/getpid.html
[2]: http://www.opengroup.org/onlinepubs/009695399/functions/kill.html"

Simon Holm Thøgersen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/