- When running
sudo <command>under a user login session, will that change
$PATHto be the root's
$PATHduring the running of
<command>relies on the user's
$PATH, not the root's
$PATH, how can the user run
One way is to
sudo suto be the root, change the root's
$PATHto be the user's, and run
<command>directly. This is how I solved my problem of How to specify a higher ruby version for installing a gem?.
Any way simpler?
- Can it be done without switching to the root from the user?
This is actually configuration-dependent. There is an
env_reset option in
sudoers that, combined with
env_delete, controls whether to replace, extend, or pass through some or all environment variables, including
The default behaviour is to have
env_reset enabled, and to reset
PATH. The value
PATH is set to can be controlled with the
secure_path option, and otherwise it is determined by the user configuration.
You can disable
env_reset or add
env_keep to change that behaviour, but note that it may not have the effect you want overall - there are often directories (
sbin) in root's
PATH that aren't in your user's. You can enable
setenv instead to allow overriding environment for a single execution of
sudo using the
-E option to
All of these could be changed in your distribution's default configuration already. Run
sudo visudo to have a look at what's currently in your
There are alternative approaches. One simple one is to use
sudo's built-in environment variable setting or
sudo PATH="$PATH" command ... sudo env PATH="$PATH" command ...
will both run just this command with your current user's
PATH. You can set other variables there as well in the same way, which is often useful. One or other of those may be disallowed by your configuration.
When running sudo under a user login session, will that change $PATH to be the root's $PATH during the running of sudo ?
sudo will change
$PATH variable, depend on your security policy. From
sudo man page:
PATH May be overridden by the security policy.
In most system,
env_reset option is enabled by default, this causes commands to be executed with a minimal environment containing
USERNAME in addition to variables from the invoking process permitted by the
env_keep sudoers options.
For security reason,
secure_path option to set the safe
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
If relies on the user's $PATH, not the root's $PATH, how can the user run sudo successfully?
Because the user's
PATH can be preserved when you run
sudo. You can always do:
sudo env "PATH=$PATH" <command>
Do you need to get an interactive login root shell?
sudo -H -i
-H The -H (HOME) option requests that the security policy set the HOME environment variable to the home directory of the target user (root by default) as specified by the password database. Depending on the policy, this may be the default behavior. -i [command] The -i (simulate initial login) option runs the shell specified by the password database entry of the target user as a login shell. This means that login-specific resource files such as .profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed. sudo attempts to change to that user's home directory before running the shell. The security policy shall initialize the environment to a minimal set of variables, similar to what is present when a user logs in. The Command Environment section in the sudoers(5) manual documents how the -i option affects the environment in which a command is run when the sudoers policy is in use.