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.


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.

  • 1
    Thanks! I missed the obvious expansion before sudo :-) I see the override of path in sudo sudo -V now, although I find that conflicting the 'Environment variables to preserve:' statement later on. I suppose I have to set the NEW path in my sudoers file to prevent the -i? – Kamiel Wanrooij Apr 15 '11 at 17:06
  • Yes, that's probably best. – justarobert Apr 16 '11 at 7:20
  • 1
    sudo echo \$PATH just produces '$PATH' for me. but your sudo sh -c 'echo $PATH' does the trick. thanks – hobs Sep 21 '12 at 19:02

Let's go by parts:

  • gemname it runs my tool correctly.

That's ok :)

  • sudo gemname it merely tells me command not found.

gemname is not in your $PATH

  • sudo echo $PATH it does show the correct path.

That's a cool one: variable expansion happens before bash runs the program. So when you run this, it expands to your user $PATH before calling sudo, so the line that is passed to sudo is more like:

$ sudo echo "/usr/bin:/bin:"
  • sudo -i gemname it runs correctly.

sudo -i runs as a login shell and honors .profile and/or .login. As by the man page says:

It also initializes the environment, leaving DISPLAY and TERM unchanged, setting HOME, MAIL, SHELL, USER, LOGNAME, and PATH, as well as the contents of /etc/environment on Linux and AIX systems. All other environment variables are removed.

  • 1
    Just a quibble: gemname is in his $PATH, as otherwise the first example wouldn't work. It's not in the sanitized $PATH that sudo (without -i) uses. – justarobert Apr 14 '11 at 1:00
  • Thanks! I assume that's the .profile of the calling user? Or root/the -u'd user? – Kamiel Wanrooij Apr 15 '11 at 17:08
  • The second option. – coredump Apr 15 '11 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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