How to keep environment variables when using sudo [closed]

Question

When I use any command with sudo the environment variables are not there. For example after setting HTTP_PROXY the command wget works fine without sudo. However if I type sudo wget it says it can't bypass the proxy setting.

Investigation

superuser.com/questions/232231/… – Parishioner

Related: Why are PATH variables different when running via sudo and su? at Unix SE – Bridgehead

Answer 1

The trick is to add environment variables to sudoers file via sudo visudo command and add these lines:

Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"

taken from ArchLinux wiki.

For Ubuntu 14, you need to specify in separate lines as it returns the errors for multi-variable lines:

Defaults  env_keep += "http_proxy"
Defaults  env_keep += "https_proxy"
Defaults  env_keep += "HTTP_PROXY"
Defaults  env_keep += "HTTPS_PROXY"

Investigation

This is arguably the best option, to avoid information leakage and security holes. sudo -E is the sure-fire way to adhoc get the same effect for a one-off, though – Insane

I encountered the problem of a process being the one who call sudo (jhbuild) and i can't tell it to pass the -E flag to sudo, so this is my solution. – Hutt

Notice that you should never edit the etc/sudoers directly. Instead, use the visudo command, which syntax-checks your edits before overwriting the sudoers file. That way, you don't lock yourself out if you make a mistake while editing. – Choe

Consider using uppercase env vars. In my case the use of HTTP_PROXY and HTTPS_PROXY did the trick. – Ketose

The syntax to restrict the Defaults to a command or user is here: unix.stackexchange.com/a/13246/66983 – Calx

lowercase variant is better from my experience as it works in both wget and curl. – Unfounded

Does editing / appending new environment variables this way take effect right away? Or does it require a server restart? I can't seem to preserve my ~/.bash_profile exported vars even after using sudo visudo to add them with Defaults env_keep += "VARNAME" – Objectify

(continue.) Nevermind, realized I was placing it too early, before the Defaults env_reset, haaa! Glad I figured that one out! – Objectify

this won't work if your env. variables are set via ~/.profile – Sham

I think this applies even to ubuntu 22.04, single liner did not work for me. – Toowoomba

Answer 2

First you need to export HTTP_PROXY. Second, you need to read man sudo, and look at the -E flag. This works:

$ export HTTP_PROXY=foof
$ sudo -E bash -c 'echo $HTTP_PROXY'

Here is the quote from the man page:

-E, --preserve-env
             Indicates to the security policy that the user wishes to preserve their
             existing environment variables.  The security policy may return an error
             if the user does not have permission to preserve the environment.

Sphygmomanometer

great the only problem that is modify some config files for example pacman for arch to make the -E is passed – Investigation

To allow -E (preserve environment) for wget, you need to specify the SETENV tag on the sudo rule that allows the running of wget -- Example: <username> ALL=(root) NOPASSWD:SETENV: <path to wget> – Pentylenetetrazol

This "-E" doesn't work if the variable is PATH or PYTHONPATH. – Elytron

Also doesn't work with any LC_* variable. So just do export LOL_FOO=$LC_FOO and use LOL_FOO instead. – Labarbera

This did not work with the simpler case of adding one element to the PATH in the .bashrc file -- say, export PATH=myPath:$PATH. If I type sudo -E bash -c 'echo $PATH', then PATH does not contain myPath probably because sudo has already disabled the local value of PATH before calling bash. Rather, I found the answer below https://mcmap.net/q/64372/-how-to-keep-environment-variables-when-using-sudo-closed effective, that is sudo PATH=$PATH command – Saccharine

Addition to the comment above. Say that package is under myPath, then sudo PATH=$PATH which package finds the right answer unlike sudo which package. However, sudo PATH=$PATH package does not go any further than sudo package (file not found). On the other hand, launching a plain package from a shell invoked with sudo bash preserves the extended path and gives package sudo rights (two pigeons with one stone). So the response really depends on which commands you are launching – Saccharine

The (setter) user may not have permission to keep environment variables: -E, --preserve-env ... . The security policy may return an error if the user does not have permission to preserve the environment. – Sideslip

@Saccharine It's an "obvious" security measure not allowing PATH by default, since the user could inadvertently execute some non-standard command with UN-expected results and root privileges. – Gamages

Remember, you can always set environment variables inline as well: HTTP_PROXY=val sudo -E bash -c 'echo $HTTP_PROXY'. – Carrycarryall

this won't work if your env. variables are set via ~/.profile – Sham

For the system I'm using, I did not have permission to run bash with sudo, but simply running sudo -E <command> worked. +1 – Mader

Answer 3

For individual variables you want to make available on a one off basis you can make it part of the command.

sudo http_proxy=$http_proxy wget "http://stackoverflow.com"

Abstain

I have tested this answer for a package under some myPath added to PATH in the .bashrc file (with export clausule). Then sudo PATH=$PATH which package finds the right answer, unlike sudo which package. However, sudo PATH=$PATH package does not go any further than sudo package (file not found). On the other hand, launching a plain package from a shell invoked with sudo bash preserves the extended path and gives package sudo rights (two pigeons with one stone). So the response really depends on which commands you are launching – Saccharine

PATH resolution for sudo is another matter - should anyone find this post in search of that matter I suggest seeing unix.stackexchange.com/questions/83191/… – Abstain

notice the order of the arguments is important, first sudo, only then the environment variable to be forwarded, then the command with its arguments. – Bismuthic

Answer 4

You can also combine the two env_keep statements in Ahmed Aswani's answer into a single statement like this:

Defaults env_keep += "http_proxy https_proxy"

You should also consider specifying env_keep for only a single command like this:

Defaults!/bin/[your_command] env_keep += "http_proxy https_proxy"

Unmoor

Answer 5

A simple wrapper function (or in-line for loop)

I came up with a unique solution because:

• sudo -E "$@" was leaking variables that was causing problems for my command
• sudo VAR1="$VAR1" ... VAR42="$VAR42" "$@" was long and ugly in my case

demo.sh

#!/bin/bash

function sudo_exports(){
    eval sudo $(for x in $_EXPORTS; do printf '%q=%q ' "$x" "${!x}"; done;) "$@"
}

# create a test script to call as sudo
echo 'echo Forty-Two is $VAR42' > sudo_test.sh
chmod +x sudo_test.sh

export VAR42="The Answer to the Ultimate Question of Life, The Universe, and Everything."

export _EXPORTS="_EXPORTS VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9 VAR10 VAR11 VAR12 VAR13 VAR14 VAR15 VAR16 VAR17 VAR18 VAR19 VAR20 VAR21 VAR22 VAR23 VAR24 VAR25 VAR26 VAR27 VAR28 VAR29 VAR30 VAR31 VAR32 VAR33 VAR34 VAR35 VAR36 VAR37 VAR38 VAR39 VAR40 VAR41 VAR42"

# clean function style
sudo_exports ./sudo_test.sh

# or just use the content of the function
eval sudo $(for x in $_EXPORTS; do printf '%q=%q ' "$x" "${!x}"; done;) ./sudo_test.sh

Result

$ ./demo.sh
Forty-Two is The Answer to the Ultimate Question of Life, The Universe, and Everything.
Forty-Two is The Answer to the Ultimate Question of Life, The Universe, and Everything.

How?

This is made possible by a feature of the bash builtin printf. The %q produces a shell quoted string. Unlike the parameter expansion in bash 4.4, this works in bash versions < 4.0

Brisk

Answer 6

Add code snippets to /etc/sudoers.d

Don't know if this is available in all distros, but in Debian-based distros, there is a line at or near the tail of the /etc/sudoers file that includes the folder /etc/sudoers.d. Herein, one may add code "snippets" that modify sudo's configuration. Specifically, they allow control over all environment variables used in sudo.

As with /etc/sudoers, these "code snippets" should be edited using visudo. You can start by reading the README file, which is also a handy place for keeping any notes you care to make:

$ sudo visudo -f /etc/sudoers.d/README 

# files for your snippets may be created/edited like so:

$ sudo visudo -f /etc/sudoers.d/20_mysnippets

Read the "Command Environment" section of 'man 5 sudoers'

Perhaps the most informative documentation on environment configuration in sudo is found in the Command environment section of man 5 sudoers. Here, we learn that a sudoers environment variables that are blocked by default may be "whitelisted" using the env_check or env_keep options; e.g.

Defaults env_keep += "http_proxy HTTP_PROXY"
Defaults env_keep += "https_proxy HTTPS_PROXY"
Defaults env_keep += "ftp_proxy FTP_PROXY"

And so, in the OP's case, we may "pass" the sudoer's environment variables as follows:

$ sudo visudo -f /etc/sudoers.d/10_myenvwlist

# opens the default editor for entry of the following lines: 
Defaults env_keep += "http_proxy HTTP_PROXY"
Defaults env_keep += "https_proxy HTTPS_PROXY"
# and any others deemed useful/necessary
# Save the file, close the editor, and you are done!

Get your bearings from '# sudo -V'

The OP presumably discovered the missing environment variable in sudo by trial-and-error. However, it is possible to be proactive: A listing of all environment variables, and their allowed or denied status is available (and unique to each host) from the root prompt as follows:

# sudo -V
...
Environment variables to check for safety: 
...
Environment variables to remove: 
...
Environment variables to preserve:
...

Note that once an environment variable is "whitelisted" as above, it will appear in subsequent listings of sudo -V under the "preserve" listing.

Ona

Answer 7

If you have the need to keep the environment variables in a script you can put your command in a here document like this. Especially if you have lots of variables to set things look tidy this way.

# prepare a script e.g. for running maven
runmaven=/tmp/runmaven$$
# create the script with a here document 
cat << EOF > $runmaven
#!/bin/bash
# run the maven clean with environment variables set
export ANT_HOME=/usr/share/ant
export MAKEFLAGS=-j4
mvn clean install
EOF
# make the script executable
chmod +x $runmaven
# run it
sudo $runmaven
# remove it or comment out to keep
rm $runmaven

Hilversum