I'm wondering about the security of UNIX signals.

SIGKILL will kill the process. So, what happens when a non root user's process sends a signal to a root user's process? Does the process still carry out the signal handler?

I follow the accepted answer (gollum's), and I type man capabilites, and I find a lot of things about the Linux kernel. From man capabilities:


   capabilities - overview of Linux capabilities

   For the purpose of performing permission checks, traditional UNIX
   implementations distinguish two categories of processes: privileged
   processes (whose effective user ID is 0, referred to as superuser or
   root), and unprivileged processes (whose effective UID is nonzero).
   Privileged processes bypass all kernel permission checks, while
   unprivileged processes are subject to full permission checking based
   on the process's credentials (usually: effective UID, effective GID,
   and supplementary group list).

   Starting with kernel 2.2, Linux divides the privileges traditionally
   associated with superuser into distinct units, known as capabilities,
   which can be independently enabled and disabled.  Capabilities are a
   per-thread attribute.
  • 5
    Other than SIGKILL, which is a special case and managed completely by the kernel, signals are merely a request. The receiving process can do anything they want with them.
    – chepner
    Commented Jan 29, 2016 at 21:57
  • 3
    @chepner Other than SIGKILL and SIGSTOP...
    – jlliagre
    Commented Jan 30, 2016 at 14:44
  • 1
    @chepner The receiving process has to actively decide it wants to handle the signal. If the receiving process hasn't done so, then a lot of signals will by default kill the process in exactly the same way SIGKILL would. Initially SIGINT, SIGKILL, and SIGTERM will have the exact same effect, the only difference is that the receiving process can change this default for some of them.
    – kasperd
    Commented Jan 30, 2016 at 15:01

4 Answers 4


On Linux it depends on the file capabilities.

Take the following simple mykill.c source:

#include <stdio.h>
#include <sys/types.h>
#include <signal.h>
#include <stdlib.h>

void exit_usage(const char *prog) {
        printf("usage: %s -<signal> <pid>\n", prog);

int main(int argc, char **argv) {
        pid_t pid;
        int sig;

        if (argc != 3)

        sig = atoi(argv[1]);
        pid = atoi(argv[2]);

        if (sig >= 0 || pid < 2)

        if (kill(pid, -sig) == -1) {
                return 1;
        printf("successfully sent signal %d to process %d\n", -sig, pid);

        return 0;

build it:

gcc -Wall mykill.c -o /tmp/mykill

Now as user root start a sleep process in background:

root@horny:/root# /bin/sleep 3600 &
[1] 16098

Now as normal user try to kill it:

demouser@horny:/home/demouser$ ps aux | grep sleep
root     16098  0.0  0.0  11652   696 pts/20   S    15:06   0:00 sleep 500

demouser@horny:/home/demouser$ /tmp/mykill -9 16098
failed: Operation not permitted

Now as root user change the /tmp/mykill caps:

root@horny:/root# setcap cap_kill+ep /tmp/mykill

And try again as normal user:

demouser@horny:/home/demouser$ /tmp/mykill -9 16098
successfully sent signal 9 to process 16098

Finally please delete /tmp/mykill for obvious reasons ;)

  • 3
    Follow your clue, I type "man capabilities" and I find a lot of thing about linux kernel
    – lovespring
    Commented Jan 29, 2016 at 14:41
  • 2
    Are we not gonna talk about the machine name here??
    – fotijr
    Commented May 6, 2021 at 2:25


strace kill -HUP 1
kill(1, SIGHUP)    = -1 EPERM (Operation not permitted)
  • 1
    Is this kind of security done by os level or hard coded in user's signal handler ?
    – lovespring
    Commented Jan 29, 2016 at 12:13
  • 4
    @lovespring The kernel doesn't deliver the signal to the target process. The syscall is returned with an error and apart from that ignored. Commented Jan 29, 2016 at 12:28
  • 1
    That is not true in general. It depends on the capabilities.
    – gollum
    Commented Jan 29, 2016 at 14:21
  • 1
    @psmears yes, but others have similar concepts (e.g. "privileges" on solaris). So the answer "Nothing" is definitely wrong.
    – gollum
    Commented Jan 31, 2016 at 15:08
  • 1
    @gollum: It's not exactly wrong (after all, it is the default behaviour on all Unix-family OSs, and the only one possible on many - including older Linux kernels for instance) but you're right that it's incomplete - but just mentioning "capabilities" without going into more detail about where they are suported is also incomplete in a question about general Unix :)
    – psmears
    Commented Jan 31, 2016 at 23:05

kill(2) man page explains:

Linux Notes

Across different kernel versions, Linux has enforced different rules for the permissions required for an unprivileged process to send a signal to another process. In kernels 1.0 to 1.2.2, a signal could be sent if the effective user ID of the sender matched that of the receiver, or the real user ID of the sender matched that of the receiver. From kernel 1.2.3 until 1.3.77, a signal could be sent if the effective user ID of the sender matched either the real or effective user ID of the receiver. The current rules, which conform to POSIX.1-2001, were adopted in kernel 1.3.78.

  • 1.3.78 is extremely ancient history, as 1.3. dates from 1995 or thereabouts. 1.3 was the development series leading up to 2.0 (in 1996)
    – vonbrand
    Commented Jan 30, 2016 at 17:41
  • @vonbrand Probably the cited man pages need some update.
    – peterh
    Commented Nov 11, 2022 at 4:04

the signal would carry but the process owner belong to root. so, the other user don't have the right to terminate the process so you will receive permission error problem.

terminate process is only possible when you own the ownership(proper rights) of the process.

  • No, sys_kill gives back -1 and errno will be -EPERM.
    – peterh
    Commented Feb 23, 2017 at 22:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .