I want to start a process as another uid and it should not need any information from $(env), so I strip the environment prior to the sudo -u powerlessuser /bin/processCmd, that is I run this

env -i sudo -u powerlessuser /bin/processCmd

it turns out sudo thinks it is necessary to repopulate the environment, which I would like to ask it not to do. There is for instance $SUDO_USER set which even tells the powerlessuser's /bin/processCmd about me(tm) that called the command, which I find very indiscrete. Any help?

It is as I figured also possible to use env -i stripping after the sudo, i.e. do this:

sudo -u powerlessuser /usr/bin/env -i /bin/processCmd

which solves the problem somewhat, yet I would really like to know if there is a way to make sudo not add any information in the first place, I browsed man 8 sudo in which I found documentation that sudo adds environment and which, but no help how to make sudo not do that

@terdon♦: I want all environment variables cleaned that are not necessary. I am unable to tell which environmental variables are necessary but just to stick to the question, I have not found the reason why $SUDO_USER would be needed by a process to be called as an unpriveledged user. Therefore I would be satisfied to know how to tell sudo not to leak SUDO_USER

Update - xy-problem issue

As much as I am very interested in avoiding anything of the kind of a xy-problem, I fear it is not the case here. That is because, I do not have actually a different problem as the one stated in the question, namely that searching a way to make sudo not do something, which I can reasonably expect: Sudo get an cleaned up environment and should at best not add stuff to it, i.e. $SUDO_USER. For this reason I am rather very convinced not to have any other problem, since I have already a cure to that issue that sudo leaves me with, i.e. I can do:

sudo -u powerlessuser /usr/bin/env -i /bin/processCmd

which "cleans up after sudo", so in no way is my problem something else, because using the subsequent env -i solved any problem there. The only thing I ask is for knowing if there would have been indeed a way like sudo --empty-env which then would spawn the new process with an emptied environment, one that at least would not tell $SUDO_USER which uid ran the original sudo.

For all that showed interest in helping me with this question, I like to thank them! I also leave some time, maybe there is such a --empty-env switch possibility. If not maybe somebody that is inside of sudo can tell, i.e. with reference to the sources that such a task is impossible, as sudo cannot but put that undesired $SUDO_USER inside.

Again no xy-problem, for the fact, that it is not really a problem to start with, i.e I do not suffer from the shortcomings of sudo here, as it is solved by a subsequent env -i, which in "unix philosophy" is the one thing that env -i does well, i.e. clean the environment. I should maybe not even have expected any reasonable behavior from sudo there, as sudo has a different one-purpose, which is not concerned about environment variables leaking. Even though, the fact that sudo does offer some flags relating to environment variables misleads into thinking it would deal with environment variables well.

  • Does sudo -E help?
    – Pandya
    Mar 13, 2016 at 12:20
  • @Pandya nice idea :). surely the preserve environment flag would not be the first comming to mind, if I explicitly intend to not preserve it. Still given that I env -i cleaned the environment, I would like to preserve a clean environment. I tried it and still sudo is poluting my $(env) with $SUDO_USER. What does this yield to you? env -i sudo -E /bin/printenv Mar 13, 2016 at 12:27
  • Please edit your question and clarify what variables you don't want to see exported. Some have to be set, do you just want them to be set to the environment that powerlessuser would get on login?
    – terdon
    Mar 13, 2016 at 14:29
  • @terdon. I have edited the question. I will have to get some knowledge about which environment variables are absolutely needed. I think people think some are needed, when indeed they are simpy useful, I have myself writen lots of programs that never ever used -at least explicitly- any information form the environment. Anyway as edited to the question, not leaking SUDO_USER would be a great start Mar 13, 2016 at 15:06

2 Answers 2


If the tool does not do what you want, you can improve it using a wrapper script. I use this script (noenv) to keep build environments clean. Using it like

sudo -u powerlessuser noenv /bin/processCmd

would do what you're asking. (The script should be in the standard path, otherwise you have to provide it path in the command).


# $Id: noenv,v 1.3 2014/05/10 22:43:32 tom Exp $
# trim the environment to minimal (PATH may still be long...)
env | sed -e 's/=.*//' -e '/^[  ].*/d' | \
while true
    read value
    if test -z "$value" ; then
        # honor assignments to variables in the parameter list
        while test $# != 0
            case "x$1" in
                eval $1
                name=`echo "$1"|sed -e 's/=.*//'`
                export $name
                shift 1
        exec "$@"
    case "$value" in
    *\ *|*\(*|*\)*|*\!*)
        #echo "...skipping $value"
        #echo value:"$value"
        unset "$value"

To clarify, I did not write this using /usr/bin/env, because some of the systems on which I was building did not have a POSIX feature which the question mentioned: the -i option. Those are old BSD systems, including SunOS 4 and HPUX 10 (checking my memory against the manual page for "env" on FreeBSD).

The script, by the way, trims out multi-line values (but the only one you might encounter is TERMCAP, and that only on very old machines). The second sed-expression is supposed to be a range with tab and space.

For POSIX (which you probably are more interested in), you could do something that uses the feature to pass in selected values from the parent environment, e.g.,

env -i foo="bar"

and so both are customizable. For a large set of variables, that can be clumsy, and a script is a better choice.

sudo disapproves of TERMCAP in any case. That is on a (long) list of variables which it helpfully removes from the environment.

sudo insists on setting certain variables. Reading the source plugins/sudoers/env.c, you will see this chunk near the end of rebuild_env:

/* Add the SUDO_USER, SUDO_UID, SUDO_GID environment variables. */
CHECK_SETENV2("SUDO_USER", user_name, true, true);
snprintf(idbuf, sizeof(idbuf), "%u", (unsigned int) user_uid);
CHECK_SETENV2("SUDO_UID", idbuf, true, true);
snprintf(idbuf, sizeof(idbuf), "%u", (unsigned int) user_gid);
CHECK_SETENV2("SUDO_GID", idbuf, true, true);


that is, just before the (only) successful return from that function, it sets its own variables, using its own values.

  • thank you for offering this script, much appreciated! Yet in relation to the question, the answer is that with sudo alone one can not really have any flag that would set sudo to explicitly not include new stuff to the environment, especially $SUDO_USER, is that correct? Mar 13, 2016 at 16:42
  • On a second note: How does the solution you offer differ from the one I included in the question itself sudo -u powerless env -i /bin/processCmd, that is, do you think that your noenv is favourable over env -i? Mar 13, 2016 at 16:48
  • 1
    Mine is customizable (and portable). Mar 13, 2016 at 16:51
  • 1
    Agree: sudo does not appear to provide the feature you want. Mar 13, 2016 at 16:53
  • thank you for this clarification. If you can substantiate, that sudo has no way of getting its "I do not leave some unwanted environment variables like $SUDO_USER"-shit together, then you could add that to your answer for me to accept it. Or maybe somebody else is able to supply such evidence in another answer. thank you also for pointing out the customizability thing. I also think it is great that you solution might be not relying on /usr/bin/env to exist, though I think one could Mar 13, 2016 at 17:03

If you are looking to unset only specific env vars, like SUDO_USER, you can filter them out when calling sudo by using the 'env -u ' option.

For example,

sudo -u powerless env -u SUDO_USER -u SUDO_UID ./some_script.sh

unsets SUDO_USER and SUDO_UID in the environment which runs the script ./some_script.sh.

Note the order, since -u has different meaning when it follows sudo vs. env.

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.