Messages in this thread | | | Date | Thu, 21 Mar 1996 12:57:09 -0500 | From | "Theodore Ts'o" <> | Subject | Re: Kill system call |
| |
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
| |