Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

in a Linux environment, I need to kill a process which has been started by user2 if I am user1 without being sudoers or using root. Do you know if there is a way of setting that when launching the process? Such as a list of users allowed to kill the process?

The fact is that concurrent instances of the same process can be started from different users, that is why it is not convenient for me to set the group id to the process. Other users that are not in the group will not be able to start a second parallel process.

What I have is a list of users allowed to start the process, defined in the database, before starting the process I check that the current user in the list and, if yes, I start the process with the current user. If a second user allowed to do that wants to kill the process I'd like it to be allowed to do that but I don't want it to be sudoers.

Therefore, I was thinking to create a process running as root which receives the request to kill processes from a user, checks if the user is allowed to start/stop the process and kills the process.

Do you think it could be the best solution?

share|improve this question

migrated from May 3 '10 at 16:45

This question came from our site for professional and enthusiast programmers.

Welcome to SO. I don't think this is possible... Anyway, this is more suitable for SO's sister site, It may get migrated there soon, no need to do anything. – Pekka 웃 May 3 '10 at 12:18
What kind of program are we talking about? It would be difficult in the general case, but in some cases (such as apache or an app that you can modify yourself) it would be easier. – Kim May 3 '10 at 12:23

I'm sorry, but this simply is not possible (that's by design). However, if members of a common group, user1 could write to a file that user2's process checks, indicating to the process that it should terminate.

Or, user2 could run something in the background that checks a file, then sends the appropriate signals. User1 then simply has to write to that file. This may be easier, as it would not require any modification of user2's programs.

Conventionally, no, user1 can not send POSIX signals to user2's process.

share|improve this answer
Thanks for your answer. In my case, indeed, I don't use the file but we use a system ( that can send the appropriate signal, then a process can be called that checks that the user is allowed to stop the process and kills the process. – ATelesca May 3 '10 at 13:31
@ATelesca - I use something very similar to allow underprivileged users to control / start / stop Xen virtual machines across a rather large farm. Basically, the same thing. – Tim Post May 3 '10 at 14:20

Unless ACLs or SELinux or something else has a better way to do it, the way I've seen this done is with a SetUID script. As you can imagine, they're infamous for being security risks.

Regarding your case, say that procOwner is the username for the process owner, and userA (uid 1000), userB (uid 1201), and userC (uid 1450) are the folks allowed to kill the process.


case ${UID} in
1000|1201|1450) ;;
*) echo "You are not allowed to kill the process."
   exit 1;;

kill ${PROCESS_ID}
# PROCESS_ID could also be stored somewhere in /var/run.

Then set the owner and permissions with:

chown procOwner:procGroup killmyproc.bash
chmod 6750 killmyproc.bash

And also put userA, userB, and userC in the group procGroup.

share|improve this answer
I tried this, and it didn't work. The non-owner user got a permission denied on the kill command. – Javid Jamae Oct 5 '11 at 20:47
I would just add, why not let the system control permissions to the kill script? Creating a group out of userA, userB, and userC, then chowning the killscript to that group and chmodding it to g+x seems way tidier to me. – Leonid Shevtsov Sep 3 '12 at 16:29
setUid bit not allowed in shell scripts, u need to crate simple wrapper compiled programm to run it – El' Aug 1 '14 at 14:16

Not conventionally -- having any user come and kill of someone else's processes is the ultimate denial-of-service vulnerability.

It can be done if the target process cooperates. One way would be for it to monitor for an external event (like a file being created in /var/tmp, or a message on a socket), instructing it to kill itself. If you can't write it to do that, you could write a wrapper for it that starts it and then does the monitoring, killing the child process if the event occurs.

share|improve this answer

No, you can't.

If you want to share processes with other users, you should start the process under a common user id.

share|improve this answer

Of course, you can write the program in such a way that it gracefully terminates when it receives a certain signal (term used loosely to mean "a pre-determined event", not a POSIX signal) from a certain (list of) users.

share|improve this answer
Signals don't have a "user" field. They are just signals. – LtWorf Jul 16 '14 at 8:43
That why I said "a pre-determined event, not a POSIX signal". – drxzcl Jul 18 '14 at 11:07

You can write a suid program that only users in a certain group may execute and which sends the appropriate signal to the process. Not sure wether you meant to exclude suid too though.

share|improve this answer

suid bit does not work with bash scripts. imho, the best way is to write some wrapper script "killservice". Suppose, that your service is running as user serviceuser

sudo -u serviceuser /usr/bin/killserviceworker


# addgroup servicekiller
# chown root:servicekiller /usr/bin/killservice
# chmod 750 /usr/bin/killservice
# adduser bob servicekiller

then, you just need to add rule in /etc/sudoers to allow them to run /usr/bin/killserviceworker as user serviceuser without asking a password:

servicekiller        ALL = (serviceuser:serviceuser) NOPASSWD: /usr/bin/killserviceworker

killserviceworker can look like this:

kill ${cat /run/}
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.