Next: Kill Example, Previous: Signaling Another Process, Up: Generating Signals
kill
There are restrictions that prevent you from using kill
to send
signals to any random process. These are intended to prevent antisocial
behavior such as arbitrarily killing off processes belonging to another
user. In typical use, kill
is used to pass signals between
parent, child, and sibling processes, and in these situations you
normally do have permission to send signals. The only common exception
is when you run a setuid program in a child process; if the program
changes its real UID as well as its effective UID, you may not have
permission to send a signal. The su
program does this.
Whether a process has permission to send a signal to another process is determined by the user IDs of the two processes. This concept is discussed in detail in Process Persona.
Generally, for a process to be able to send a signal to another process, either the sending process must belong to a privileged user (like `root'), or the real or effective user ID of the sending process must match the real or effective user ID of the receiving process. If the receiving process has changed its effective user ID from the set-user-ID mode bit on its process image file, then the owner of the process image file is used in place of its current effective user ID. In some implementations, a parent process might be able to send signals to a child process even if the user ID's don't match, and other implementations might enforce other restrictions.
The SIGCONT
signal is a special case. It can be sent if the
sender is part of the same session as the receiver, regardless of
user IDs.