root can kill any program run by any user. Is it possible for a user to kill another user's program without using sudo, etc.?

Example: How can make user foo kill program x which is run by user bar?

  • Is there any reason why you want to do this? – Nils Oct 7 '11 at 20:48
  • There are reasons I would want to do this. Memory is a limited resource on the shared cluster I use and sometimes people leave memory-eating processes paused for a long time. I would enjoy being able to kill those processes without asking them to. – NeutronStar Jun 25 '14 at 16:37
  • I found my answer right here on stackexchange unix.stackexchange.com/questions/185903/… bash is interactive, in the absence of any traps, it ignores SIGTERM I was running bash in interactive mode – Dwayne Nov 24 '15 at 20:31

This is from the kill(2) manpage:

For a process to have permission to send a signal it must either be privileged (under Linux: have the CAP_KILL capability), or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the target process. In the case of SIGCONT it suffices when the send‐ ing and receiving processes belong to the same session.

So essentially, under normal circumstances, if you are not root (and have no way to become root or that other user, via sudo or setuid programs), you cannot kill another user's process.


It's only possible for root and bar to kill a process owned by bar. Sudo/setuid programs change foo's privileges to those of root.


See Gilles answer at Why does bash ignore SIGTERM?

First, this isn't specific to bash. ATT ksh, dash and zsh behave the same way: they ignore SIGTERM and SIGQUIT during command line edition; as for mksh, it also doesn't quit but treats them like SIGINT.

Both the ksh manual and the bash manual justify ignoring SIGTERM in these terms:

so that kill 0 does not kill an interactive shell

kill 0 kills all processes in the process group that the shell is in¹. In a nutshell, the process group consists of all the processes running in the foreground on a terminal, or all the processes in a background or suspended job.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.