Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have two computers, one running Xubuntu 12.04, and the other running Linux Mint 14.

On Xubuntu:

$ sudo gedit

in another terminal:

$ kill [pid of the gedit process]
bash: kill: ([pid]) - Operation not permitted

$ kill [pid of the sudo process]

This last one actually successfully kills sudo (and gedit with it), even though sudo is run as root (setuid) and a normal user should not be able to kill root's processes. But my guess is, because we started it ourself, we somehow have special rights over it.

On Mint:

$ sudo gedit

in another terminal:

$ kill [pid of the gedit process]
bash: kill: ([pid]) - Operation not permitted

$ kill [pid of the sudo process]
bash: kill: ([pid]) - Operation not permitted

So why can we kill sudo as a normal user on Xubuntu but not on Mint? What causes this? How can I change this behavior?

I am not looking for ways to kill processes, obviously sudo kill would work.

share|improve this question
1  
You could always do sudo kill PID. –  terdon Mar 12 '13 at 12:57
    
@terdon: thanks, but I'm not looking for a solution to killing the sudo process, but I want to understand what's going on, what's causing this difference in behavior, and where/how this could be changed. –  stk Mar 12 '13 at 13:05
    
@stk what @terdon meant was that you should use the syntax sudo kill PID where PID stands for the process ID of the process you are trying to terminate. –  Lorenzo Von Matterhorn Mar 12 '13 at 13:09
    
@Znau: Of course I can kill any process as root, the question is why I can "magically" kill it as a normal user in the case demonstrated above, and why the same does not work on a very similar OS. After all Xubuntu and Mint are both descendants of Ubuntu. So, is this something one could change in a config file somewhere? Or does it come from different kernel versions/options? Or something else altogether? –  stk Mar 12 '13 at 13:17
    
@stk your visudo might be changed –  Lorenzo Von Matterhorn Mar 12 '13 at 13:26

3 Answers 3

This is probably better served in a comment, but I can't post comments yet. Try a

ps aux | grep sudo

and look at the user (owner) of that sudo process. It may be possible that the sudo process is being ran as your user instead of root.

I just tried on my Red Hat system and was unable to kill the sudo process from my local normal user, as it was owned by root.

share|improve this answer
    
nope, on both machines sudo runs as root –  stk Mar 12 '13 at 15:02

I would venture to say this is a difference between REAL userid and EFFECTIVE userid for a given process and how exactly sudo operates on each of your two machines.

MINT appears, when sudoing a process, to change both the effective user id (root) and the real user id (the user who invoked the process) to root. Thus the original user cannot kill either the sudo process or the sudoed process (gedit). Xubuntu (and, in my case, Fedora) do not do this. The real userid is still the original user.

Use the ps command to see process owned by users (real or effective). I ran your sudo gedit command. ps uaxf produced this tree:

myuserid  22868  0.0  0.0 163400  4872 pts/2   Ss   13:19  0:00   |  \_ -zsh
root      30392  0.0  0.0 205044  3736 pts/2   S+   13:45  0:00   |  | \_ sudo gedit
root      30417  0.0  0.1 699788 23692 pts/2   Sl+  13:45  0:00   |  |   \_ gedit

Clearly the effective user id for both sudo and gedit are root, and not myself. Then I used ps with the --User option (--User userlist Select by real user ID (RUID) or name.) to see who the real userid for the processes are:

ps --User "myuserid" 

This produced a lot of output, but there was one line that stood out:

30392 pts/2    00:00:00 sudo

But the process 30417 was conspicuously missing...

Then I ran:

ps --User "root"

This also produced a lot of output, but this line stood out:

30417 pts/2    00:00:00 gedit

But process 30392 was absent.

So, It seems that eventhough the sudo process (30392) has an effective owner of root, the real owner is me, and I'm able to kill it. The gedit process, on the other hand, has both effective and real ownership by root and is not (directly) killable by me. I'd guess that on Lint, both process are both effectively and really owned by root.

I thought this might be affected by the stay_setuid option in /etc/sudoers, but the description of that doesn't really make this seem likely.

Are there any differences in your /etc/sudoers files between Mint and Xubuntu?

share|improve this answer

In both cases running the command as root will kill the process. The reason why it does not work in Mint is probably because there is no "automatic elevation" manager in the desktop environment like there is in ?buntu.

See: Ubuntu: automatic admin elevation?

The question is not exactly relevant, but the accepted answer touches on the cause of the perceived difference.

share|improve this answer
    
hm, I'm doing this from the command line, not in the "desktop environment" (I guess you mean file manager, i.e. Thunar/Nemo), so I don't see any relevance here –  stk Mar 13 '13 at 16:59
    
No, I mean Xfce or Gnome (assuming Mint uses Gnome). The baseline is that there is a "password manager" in ?ubuntu that allows you to run sudo commands without re-entering the password. If you are running the command while logged in as root in either a virtual console, through sshd, or in a GUI terminal emulator - the command will not exit with "permission denied", period. The mere fact that your prompt reads $ indicates that you are not logged in as root. The fact that it works on Xubuntu indicates some kind of automatic privilege elevation. –  Ярослав Рахматуллин Mar 13 '13 at 17:17

Your Answer

 
discard

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

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