I have a script that sets several environment variables and then finally calls another script using sudo.

The script run with sudo must be able to pick up those variables, and I'm not always going to be certain what those variables are.

Is there a way of configuring this sudoers entry to allow the command complete access to the callers env vars?

%deploy ALL=NOPASSWD: /bin/build.sh

When I run the sudo command from my script:

sudo -E build.sh "$@"

I get:

sudo: sorry, you are not allowed to preserve the environment

Googling around I've only found ways to preserve specific variables and not just everything.

  • 1
    What Unix are we talking about here? Different Unixes have different sudo implementations.
    – slm
    Sep 30, 2013 at 14:44
  • 2
    Note that allowing users to call a shell script as any user without imposing restrictions on the environment is equivalent to giving them super user access. Sep 30, 2013 at 14:56
  • Agree with Stephane, what you're trying to do is a bad idea from a security standpoint! User's can play games and put things into their path and elevate the credentials that this script is being run as.
    – slm
    Sep 30, 2013 at 15:41
  • Thanks, I changed how my script works a bit so that it doesn't rely on env vars to run.. instead it reads a config file. Seemed more sane. I did have a feeling I was doing something a little bit dodgy..
    – John Hunt
    Oct 1, 2013 at 11:01
  • Use a config file, preferably in a location that non-root users can't get at. Oct 1, 2013 at 11:59

3 Answers 3


After testing the first answer and still getting sudo: sorry, you are not allowed to preserve the environment, I decided to look around for a better solution.

After a bit of testing, I found that the option that matters is setenv.

Defaults!/bin/build.sh setenv

To make it a little more secure, we can add a couple settings:

Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11/bin"
Defaults!/bin/build.sh setenv,env_reset,env_delete+=PATH,env_delete+=LD_PRELOAD,env_delete+=LD_LIBRARY_PATH,env_delete+=SSH_AUTH_SOCK,env_delete+=PYTHONPATH,env_delete+=PERL5LIB
%deploy  ALL=(ALL) NOPASSWD: /bin/build.sh *

If you want to allow users in the deploy group to run any command with almost any environment variable:

Defaults:%deploy !env_reset,env_delete-=PYTHONPATH,env_delete-=PERL5LIB
%deploy ALL = (ALL) ALL

Run sudo -V to see which variables are deleted.

There is little point in restricting the command if you allow the user to preserve all environment variables, as this is likely to allow the user to run arbitrary code via some variable.

If you've carefully reviewed your script and you're sure that you have an exhaustive list of environment variables that need to be removed, you can specify that these environment variables should be deleted and all others should be kept.

Defaults!/bin/build.sh !env_reset,env_delete+=DANGEROUS_VAR
%deploy ALL = (ALL) /bin/build.sh
  • If the sudo implementation provides it, I would always prefer to define a whitelist using the env_keep option. And this list should definitely not include something like PATH, LD_PRELOAD or PERL5LIB.
    – Dubu
    Oct 2, 2013 at 8:51
  • @Dubu The whole point of this question was to allow unknown variables to get through, so not whitelisting. Allowing arbitrary variables (even PATH, LD_PRELOAD, whatever) to go through is not a security hole if you allow any command to be run: it's only a security hole if you want to restrict the command, because a lot of variables allow working around the command restriction. Oct 2, 2013 at 10:04

Run sudo visudo and comment out the two lines shown below. Commenting out only env_reset does not work

#Defaults       env_reset
Defaults        mail_badpass
#Defaults       secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
  • 6
    I don't think it's a good idea to recommend a solution that causes all environment variables to be preserved for all invocations of sudo by all users.
    – Celada
    Oct 7, 2014 at 0:03
  • That's a subjective statement. I am the only user of my machine, don't download untrusted content, and I'm well versed in Linux CLI. There's no reason for me to have training wheels on my system that just slow me down. That being said, if I set up a multi-user system, I'd have a limited list of sudoers, and I'd make sure they're well versed so that they don't need training wheels.
    – MishaP
    Oct 7, 2014 at 23:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .