Why does sudo not add root's PATH with Ubuntu 12.04?

Question

I've recently upgraded my server to Ubuntu Server 12.04. Previously it was running 11.04.

Ever since then I've been having trouble carrying out root user commands through sudo. An example of this would be:

> sudo ufw status
sudo: ufw: command not found
> sudo su - root
> ufw status
Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    LIMIT       Anywhere

With Ubuntu 11.04 the plain sudo ufw status worked fine, but with Ubuntu 12.04 it can't find the command.

This seems to just be a problem with the PATH not being set (ufw is found in /usr/sbin/ufw).

What I'm trying to understand is what I need to change back so that root's PATH is set correctly when I just sudo <sbin command>?

Solution 1

Besides security reasons (as Anders has referred to), keeping the original user's PATH also conforms to the Principle of Least Astonishment.

Suppose you run a program called foo, but discover that you really need to run it as root. So you run sudo foo. It would be bad if the program run by sudo foo is different from the program run by foo, which would happen if there's a different foo in root's PATH. This would fundamentally violate your expectations and the general assumption that sudo does the same thing as what you put after it, except as root.

That's what would happen if sudo prepended root's PATH to your PATH. But suppose sudo appended root's path to your PATH. If this was sudo's behavior, then you'd probably assume that if you can run a program (call it bar) when simulating an initial root login shell (sudo -i), you could also run it with sudo bar. But that assumption would be wrong, because there might be a different bar in your own (i.e., not root's) path.

Rather than sudo's behavior changing from one Ubuntu release to another, what probably happened was that your PATH changed. If you add /sbin, /usr/sbin, and /usr/local/sbin to your PATH, the problem will be solved. Unless you only want sbin in your PATH when running programs as root. In that case, I recommend posting a separate question about that (though one technique for accomplishing this is hinted at in Anders's answer.)

Solution 2

Have you looked into the man page for sudo? In the section SECURITY NOTES they talk about how sudo uses the PATH variable.

You also want to look into /etc/sudoers as the PATH can be changed there with secure_path. Settings can also be done by files in the directory /etc/sudoers.d/.

It is suggested to make changes to your sudo configuration by creating files in /etc/sudoers.d/ because then your changes will remain independent of changes to /etc/sudoers that might occur when upgrading sudo to a new version. You should still use the visudo command to create and edit files in /etc/sudoers.d/.

Comments

[vestigal]

Since couling was questioning his memory of whether this used to be different on an older version of Ubuntu, I'd like to confirm that this was indeed the case. On Ubuntu 10.04.4 LTS, at least the path /usr/sbin/ was appended to the PATH of the user that sudo executed its command as.

[Philip Couling]

Its very odd that I've never hit this before. The documentation points towards this being the correct action. I can't find anything significant that has changed in my sudoers file (when checking against the backup). I'll use secure_path to resolve the issue.

[Philip Couling]

After asking this question I've been wondering if I actually want it. You put forward clear reasoning for not doing. I'm on the verge of installing a sandbox version of 11.04 just to prove to myself that it hasn't always been this way. Just for the record, when I did the upgrade I made sure that the following files were not changed: /etc/sudoers /etc/profile /etc/bash.bashrc. I also made sure there were no user .profile and .bashrc files for my user or root. I can't see a logical reason for this having changed and am starting to question my memory.

[Philip Couling]

Accepting this answer because regardless of what I think I'm used to, appending /sbin/ and /usr/sbin to my own path is (I feel) the right way to fix this.