What is the difference between the following commands:

sudo -s
sudo -i
sudo bash

I know for su I need to know the root password, and for sudo I have to be in the sudoers file, but once executed what is difference?

I know there is a difference between su and sudo -s because my home directory is /root after I execute su, but my home directory is still /home/myname after sudo -s. But I suspect this is just a symptom of an underlying difference that I'm missing.


3 Answers 3


With su, you become another user — root by default, but potentially another user. If you say su -, your environment gets replaced with that user's login environment as well, so that what you see is indistinguishable from logging in as that user. There is no way the system can tell what you do while su'd to another user from actions by that user when they log in.

Things are very different with sudo:

  • Commands you run through sudo execute as the target user — root by default, but changeable with -u — but it logs the commands you run through it, tagging them with your username so blame can be assigned afterward. :)

  • sudo is very flexible. You can limit the commands a given user or group of users are allowed to run, for example. With su, it's all or nothing.

    This feature is typically used to define roles. For instance, you could define a "backups" group allowed to run dump and tar, each of which needs root access to properly back up the system disk.

    I mention this here because it means you can give someone sudo privileges without giving them sudo -s or sudo bash abilities. They have only the permissions they need to do their job, whereas with su they have run of the entire system. You have to be careful with this, though: if you give someone the ability to say sudo vi, for example, they can shell out of vi and have effectively the same power as with sudo -s.

  • Because it takes the sudoer's password instead of the root password, sudo isolates permission between multiple sudoers.

    This solves an administrative problem with su, which is that when the root password changes, all those who had to know it to use su had to be told. sudo allows the sudoers' passwords to change independently. In fact, it is common to password-lock the root user's account on a system with sudo to force all sysadmin tasks to be done via sudo. In a large organization with many trusted sudoers, this means when one of the sysadmins leaves, you don't have to change the root password and distribute it to those admins who remain.

The main differences between sudo bash and sudo -s are:

  1. -s is shorter than bash

  2. You can say sudo -s some-command to run some-command under your default shell, but with superuser privileges. It's basically shorthand for sudo $SHELL -c some-command.

  3. You can instead pass the commands to the shell's standard input, like sudo -s < my-shell-script. You could use this with a heredoc to send several commands to a single sudo call, avoiding the need to type sudo repeatedly.

  4. Even without these extra command arguments, sudo -s still differs from sudo bash in that it might run a different shell than bash, since it looks first in the SHELL environment variable, and then if that is unset, at your user's login shell setting, typically in /etc/passwd.

The shell run by sudo -s inherits your current user environment. If what you actually want is a clean environment, like you get just after login, what you want instead is sudo -i, a relatively recent addition to sudo. Roughly speaking, sudo -i is to sudo -s as su - is to su: it resets all but a few key environment variables and sends you back to your user's home directory. If you don't also give it commands to run under that shell via standard input or sudo -i some-command, it will run that shell as an interactive login shell, so your user's shell startup scripts (e.g. .bash_profile) get run again.

All of this makes sudo -i considerably more secure than sudo -s. Why? Because if someone can modify your environment before sudo -s, they could cause unintended commands to be executed. The most obvious case is modifying SHELL, but it can also happen less directly, such as via PAGER if you say man foo while under sudo -s.

You might say, "If they can modify PAGER, they can modify PATH, and then they can just substitute an evil sudo program," but someone sufficiently paranoid can say /usr/bin/sudo /bin/bash to avoid that trap. You're probably not so paranoid that you also avoid the traps in all the other susceptible environment variables, though. Did you also remember to check EDITOR, for example, before running any VCS command? Thus sudo -i.

Because sudo -i also changes your working directory to your user's home directory, you might still want to use sudo -s for those situations where you know you want to remain in the same directory you were cd'd into when you ran sudo. It's still safer to sudo -i and cd back to where you were, though.

Another variant of all this that you sometimes see is sudo su, which is approximately equivalent to sudo -s. Likewise, sudo su - is functionally quite close to sudo -i. Since sudo and su are competing commands, it's a little odd to pair them like this, so I recommend that you use the sudo flags instead.

  • 4
    What do you mean by 'shell out of vi'?
    – crisron
    Oct 20, 2014 at 5:01
  • 19
    @crisron: From within vi, type :sh and hit Enter. Now you're in a sub-shell, with all the privileges of the vi process that spawned that shell. If vi is running with root privileges, so will the shell. Or, you can run something other than a shell via :!cmd, read output from a command into the edit buffer via :r !cmd, etc. If all those are locked down, Makefile targets are shell scripts, and Vim has the :make command, which effectively lets you run arbitrary shell scripts from within the editor. The possibilities for mischief are far too immense for this comment box to hold. Oct 20, 2014 at 5:57
  • 2
    if someone can put a fake in bash in your PATH then that someone can put a fake sudo in your PATH. to be really sure you have to invoke sudo using the full path: /usr/bin/sudo
    – Lesmana
    Aug 2, 2015 at 19:35
  • 14
    Great explanation; great headache reading it.
    – lobi
    Oct 1, 2015 at 16:53
  • 2
    @lobi is right, unfortunately. But aside from that, there's an aspect I don't see covered here: is there any advantage to using sudo su -?
    – Wildcard
    Mar 2, 2017 at 5:26

From an ubuntuforums post I made a while ago:

Consider the following experiment:

applic@ion:~% sudo su
[sudo] password for applic:
root@ion:/home/applic# env > /tmp/sudo_su_env
root@ion:/home/applic# exit
applic@ion:~% sudo -s
applic .bashrc read...
root@ion:~% env >/tmp/sudo_s

Here are the differences I found:

With sudo -s:

reads $USER's ~/.bashrc

With sudo su:

reads /etc/environment
reads /root/.bashrc

Notice the difference in $HOME. Being root and having $HOME set to the normal user's home can cause problems. For example, if you run a graphical app, the normal user's ~/.Xauthority can get overwritten by root. This causes the normal user problems later on such as not being able to run certain graphical apps through cron.

To summarize:

                                     corrupted by user's 
        HOME=/root  uses root's PATH     env vars
sudo -i     Y       Y[2]                 N
sudo -s     N       Y[2]                 Y
sudo bash   N       Y[2]                 Y
sudo su     Y       N[1]                 Y
  1. PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games probably set by /etc/environment
  2. PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin

The bottom line is sudo -i is the proper command to run when you want a root shell that is untainted by the user's environment.

  • 3
    How much the environment is 'tainted' depends on the configuration of sudo (in /etc/sudoers and related files) as well. Configuration settings such as always_set_home, env_reset, env_keep, env_check and env_reset, and these may vary depending on the user and command. See the 'Command environment' and SUDOERS OPTIONS section of of the sudoers(5) manpage.
    – cjs
    Dec 7, 2017 at 11:35
  • Personally, I go with sudo -Hs when I want an environment untainted by my settings, because I use zsh and all of the application accounts I might be changing to use bash. This does let a certain number of environment variables pass unmolested, but I typically find the ones that matter get overwritten by /etc/profile.d/*.
    – Ed Grimm
    Feb 12, 2019 at 2:49
  • 3
    There is no reason for sudo su ever. Please stop typing it and publishing it. Nov 22, 2019 at 15:10

su (switch user or substitute user) lets you switch user. su basically starts another shell instance with the privileges of the intended user. By default it switches you to the root user, if we want to switch specific user we need to pass user as follows:

$ su bob  # switches to bob (requires bob's password)

su - means environment variables will be reset to root and su means environment variables as old user.

for example: root's home directory if you use su - or old user home directory if you use su.

sudo (super user do) is a command-line utility that allows users to run programs with the security privileges of another user, by default is superuser i.e root. It uses a config file /etc/sudoers which lists which users have rights to specific actions

sudo should be read as /ˈsuːduː/. syntax sudo command i.e. switch user and do this command.

  • su is equivalent to sudo -i and simulates a login into the root account. Your working directory will be /root, and it will read root's .profile etc. The prompt will change from $ to #, indicating you have root access.

  • sudo -s launches a shell as root, but doesn't change your working directory.

  • sudo bash where bash is command to run with sudo. This command runs bash as a super user.

  • Using sudo can be logged everything someone does.
  • Using sudo prevents a user from having to know the root password.
  • Using sudo we can limit the commands are allowed to run.
  • 1
    a plain su doesn't change working directory. Mar 3, 2020 at 19:09

You must log in to answer this question.

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