I'm trying to find out if its possible to execute a Bash script by another user or way than the user who is logged in or by sudo -u otherusername.

I have a script with line: echo $USER. echo $SUDO_USER this should always show me the user that executed that script.

From this Q&A I gathered that some user could use sudo and so the variable SUDO_USER or ${SUDO_USER:-$USER} could show which user executed a Bash script whether invoked by the logged in user or an user using sudo.

I cannot think of another way to execute a Bash script than with a logged in user or with sudo. So is there another way to execute a script than the above mentioned methods and would the command echo $USER or echo ${SUDO_USER:-$USER} then be showing the "original" username?

In other words is it possible to hide your username from $USER or $SUDO_USER when executing a script?

I searched for it on the internet but i did not find any answer, search keywords used: "bash invoke script obfuscating username".

Probably the answer is no but since anything is possible... some hack or spoof of some sort is maybe possible...

  • 1
    Are you aware that sudo can run commands as any user, not just as root? is that an acceptable solution or do you need this to happen in systems with no sudo installed? Also, what operating system is this about?
    – terdon
    Jul 21, 2021 at 15:52
  • The question is unclear. What do you want to achieve? If it's just that echo $USER shows a different value, you can set the environment variable USER. This does not change anything about the program's privileges, it just changes the value of the variable. If you actually want to run as a different user, then why not use sudo? What do you call “the correct username”? With multiple users involved, there isn't a single user name. Jul 21, 2021 at 15:59
  • @terdon I'm using Debian 10, sudo is installed and i did not know that the target user would be recorded in the $USER variable when sudo -u username would be used. My goal is to catch the original user using sudo or not using sudo. I guess i need to do some more digging into sudo.
    – smj
    Jul 21, 2021 at 16:12
  • @Gilles'SO-stopbeingevil' 'SO- stop being evil' What i mean with correct username is the original user invoking the script whether he's using sudo or not.
    – smj
    Jul 21, 2021 at 16:17
  • In the sudo case, do you mean the user who ran sudo or the user that sudo switched to? And either way, what do you want to do with this information? Jul 21, 2021 at 16:24

2 Answers 2


You can use sudo to run commands as any user (as long as you have sudo access):

$ cat ~/scripts/foo.sh
echo $USER

$ ~/scripts/foo.sh

terdon@tpad ~ $ sudo -u bib ~/scripts/foo.sh

So just run your script with sudo -u USERNAME where USERNAME is the user name of the target user.

The SUDO_USER variable has the username of the user who ran the sudo command, but the USER variable will be the target user:

$ cat ~/scripts/foo.sh
echo "sudo command was run by $SUDO_USER but I am actually $USER"

$ sudo -u bib ~/scripts/foo.sh
sudo command was run by terdon but I am actually bib
  • Thank you Would there be a variable or a way to find the user who used sudo and the target user?
    – smj
    Jul 21, 2021 at 16:08
  • @smj what do you mean? That's what the second script is showing you: SUDO_USER is the user who used sudo and USER is the target user.
    – terdon
    Jul 21, 2021 at 16:15
  • I think you are right but my question is if there's another way to invoke a script which is not logged by the USER or SUDO_USER variable ? I think i will edit my question better.
    – smj
    Jul 21, 2021 at 16:21
  • @smj yes, please edit and clarify. And what should happen if I ssh into a machine as terdon, then use su - to become root, then use su bob to become bob. Who is the "logged in" user now? What would you expect to see? Basically, why does it matter who is logged in? Is it to know what settings/files will be read or is it to track suers for security?
    – terdon
    Jul 21, 2021 at 16:47
  • It is to track users to see who executed the script, so for security. I like your example it could involve three different users to be tracked. I would expect to see bob as USER and root as SUDO_USER. Ultimately I would need to know who ssh'd into the machine as that is the user who needs to be identified. I guess some ssh.log or auth.log parsing would be needed to be done.
    – smj
    Jul 21, 2021 at 17:49

I'm answering the question as asked. But please beware that the way this question is worded makes me think you don't understand how the system works, and using this answer without caution is likely to result in an insecure system.

From the link above i gathered that some user could use SUDO and so the variable SUDO_USER or ${SUDO_USER:-$USER} could show which user executed a Bash script whether invoked by the logged in user or an user using SUDO.

The part about sudo is true, the part about not using sudo isn't. If you have a sudoers rule like

@staff ALL = (priya) /usr/local/bin/myprogram

then when myprogram runs, it can be confident that if the program was invoked through this sudo rule, then the SUDO_USER variable is set to the user who invoked sudo myprogram. A corollary is that if SUDO_USER is not set, then the whoever ran myprogram had some other ways to access the user account that myprogram is running as.

As a consequence, if myprogram is supposed to take some action on behalf of another user, and the only way to access the priya account for non-administrators is through this rule, then myprogram can securely access priya's resources on behalf of the user indicated by SUDO_USER.

If myprogram is running without elevated privileges, then whoever ran it can choose how they run it. They can set whatever environment variables they like. The USER variable is a convention, it has no relevance to security. But anyway, if myprogram is running without elevated privileges, it can trust USER if it wants to. Security requires elevated privileges. If you wanted to ship an executable program as a black box and check that only certain users can run it, forget it: that's impossible, and anyone who claims otherwise is selling snake oil.

In other words is it possible to hide your username from $USER or $SUDO_USER when executing a script?

That's not the same question! As I explained above, it's absolutely trivial to set USER and SUDO_USER when running a script. There is one case where it isn't, which is if the user is running sudo and telling it to run a script (as opposed to running the script directly). Only in that case, assuming a default sudo configuration, USER is guaranteed to be the user running the script and SUDO_USER is guaranteed to be the user who invoked sudo.

Note that if what happens is a sudo rule that invokes program1 which in turns invokes program2, program2 can only trust these variables if it trusts program1 not to change them.

I cannot think of another way to execute a Bash script than with a logged in user or with SUDO.

Any other service that invokes programs. A very common one is cron. Typically a user logs in and edits a crontab; but after that, the cron job runs without the user being “logged in” in the sense of being in front of the computers or having entered credentials. The user is “logged in” inasmuch as cron counts as a login (which is a matter of terminology).

There are also other ways to invoke a program with a different account, for example su (which requires credentials for the target account) and pkexec (which normally requires credentials for the target account, but more complex policies are possible). Or the program can be running inside a namespace or container of some kind (there are too many kinds to list here).

Under Linux, there's also a concept of “loginuid”. This value is supposed to be set when the user logs in and does not change when the user changes to another account. For example, su - or sudo -i follows the normal process for logging in a user (setting limits, invoking .profile, etc.), but they do not change the loginuid. You can retrieve the loginuid from /proc/self/loginuid or with the logname command. This is mainly intended for auditing. Note that by default, root can change the loginuid. Note also that the loginuid is a per-process concept, there is no global concept of a single logged-in user.

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.