Ubuntu – How does `sudo` search the path for executables

rubygemssudoUbuntu

I am using rubygems (1.3.7) with gems that require root privileges on Ubuntu 10.10. When I compare my setup to an ubuntu 9.10 with rubygems 1.3.6 installation, I see the following difference in gem environment:

1.3.7 / 10.10 - EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin

1.3.6 / 09.10 - EXECUTABLE DIRECTORY: /usr/bin

The output is the same whether I use sudo or not. To fix this (I don't know why it is different in the first place), I tried to modify my path variable.

My question is, where does sudo look for executables? If I install a gem (using sudo) the executable is placed in the /var path obviously. I added this path to my ~/.profile and /etc/environment files, but I cannot get sudo to execute the executables.

If I run:

  • $ gemname it runs my tool correctly.
  • $ sudo gemname it merely tells me command not found.
  • $ sudo echo $PATH it does show the correct path.
  • $ sudo -i gemname it runs correctly.
  • $ sudo sudo -V shows that the PATH is preserved.

Does sudo honour ~/.profile and/or /etc/environment? If so, they why can't it find my executable while the directory is shown in the $PATH environment variable?

I have read the documentation of sudo, I also search and looked through a ton of topics on stackoverflow and serverfault (for instance How to override a PATH environment variable in sudo?, but my example shows that $PATH contains the correct path), but they never actually show how to run a gem via sudo.

Best Answer

Note that, in your third command, your shell expands $PATH before sudo gets to see it, and so the output is your shell's path, not the PATH that sudo sees. What you want is something like sudo echo \$PATH or sudo sh -c 'echo $PATH'.

Beyond that, take a look at the SECURITY NOTES section of the sudo(8) man page. I believe that Ubuntu builds sudo with the SECURE_PATH build option. Look for the "Value to override user's $PATH with" line in the output of sudo sudo -V.

sudo -i simulates an initial login, and so will read files like .profile (though which files it reads depends on what root's shell is). Without -i, it inherits the preserved environment variables from its caller's environment, with the PATH sanitation I mentioned above.

As for why the path changed in the first place, I suspect that the change was a deliberate choice on the part of the developers. See more discussion on bugs.debian.org.

Related Topic