Re: Kill system call

Theodore Ts'o (tytso@mit.edu)
Thu, 21 Mar 1996 12:57:09 -0500


Date: Thu, 21 Mar 1996 07:42:24 +0000
From: Nick Randell <nick@metrica.co.uk>

I have a process, which forks off a child. The child process has a
different EUID to the parent. The child sends the parent a signal to
check that it is still alive, but the kill system call returns EPERM
whereas on all the other unix systems the software is running on the
call returns 0.

I have patched the applications source code to check for EPERM on Linux
but the reply I got mentioned that the Linux kernel handling is
incorrect.

If it looks as though we are heading towards a POSIX.1 compliant-ish
kernel and I think this is covered by POSIX 1, then could someone, maybe
from the Linux-FT team, fix this please.

POSIX.1 states:

3.2.2.2 Description of kill()

"...If sig is zero (the null signal), error checking is performed, but no
signal is actually sent. The null signal can be used to check the
validity of pid...."

3.2.2.4 Errors

"If any of the following conditions occur, the kill() function shall
return -1 and set errno to the corresponding value:

....

[EPERM] The process does not have permission to send the signal
to any receiving process."

So technically, what we're doing is allowed by POSIX.1, and POSIX is
somewhat ambiguous about whether or not the OS must return an error when
sig is 0 and you don't have permission to send a signal to the process.

My read on the standards language is that what we are doing now is
definitely in compliance, but adding an extension to so that any process
is allowed to send the null process to any other process is *probably*
within the bounds allowed by POSIX.1, as long as we so documented this
in our POSIX.1 conformance document. (Generating this document is part
of the POSIX.1 conformance process which Linux-FT spent a very large
amount of money to obtain the POSIX.1 certification.)

- Ted