95

To launch a root shell on machines where the root account is disabled, you can run one of:

  • sudo -i : run an interactive login shell (reads /root/.bashrc and /root/.profile)
  • sudo -s : run a non-login interactive shell (reads /root/.bashrc)

In the Ubuntu world, I very often see sudo su suggested as a way to get a root shell. Why run two separate commands when one will do? As far as I can tell, sudo -i is equivalent to sudo su - and sudo -s is the same as sudo su.

The only differences seem to be (comparing sudo -i on the left and sudo su - on the right):

screenshot of meld comparing 'sudo -i' and 'sudo su -'

And comparing sudo -s (left) and sudo su (right):

screenshot of meld comparing 'sudo -s' and 'sudo su'

The main differences (ignoring the SUDO_foo variables and LS_COLORS) seem to be the XDG_foo system variables in the sudo su versions.

Are there any cases where that difference warrants using the rather inelegant sudo su? Can I safely tell people (as I often have) that there's never any point in running sudo su or am I missing something?

terdon
  • 242,166
  • 8
    I've never understood those fancy systems like ubuntu which prevent users from standard su -. They created problem and now there are endless discussions on how to solve it. – jimmij Jul 24 '15 at 14:30
  • 19
    @jimmij Don't you need to know root password with su -? Don't you think that poses a security hole in multi-user environments, where more than one person needs to have root access? – Erathiel Jul 24 '15 at 15:03
  • 5
    @Christopher The problem is not one of the user that have sudo privilege or the root password to hack the system. The problem is about password safety. When you change the root password, you need to let all users who needs it to know, which can be difficult. With sudo, you don't have this difficulty. – Huygens Jul 24 '15 at 20:24
  • 4
    What is the diff tool? – Josh The Geek Jul 24 '15 at 20:49
  • 2
    @Christopher I do think that there is a difference in security in not having to distribute a shared password. With sudo, a users root enabling password never has to leave their control. (We do not live in a world where people refrain from insecure password practices, especially when it involves sending it to others.) Apart from that, it is useful to be able to restrict users to only being able to run a few commands with sudo, if all a user needs root access for is to restart a service, why give them full root access? – Phizes Jul 24 '15 at 23:03
  • 6
    @jimmij How does Ubuntu prevent the use of su -? Yes, one would have to set a root password, but that's trivial. – Phizes Jul 24 '15 at 23:05
  • 1
    I'm pretty sure you can configure sudo and prevent a root password. – Samuel Edwin Ward Jul 24 '15 at 23:10
  • 1
    @Christopher I didn't say it was a security hole. I said it was a difference. I took the prior use of security hole as being a lack of the precise terminology you may find to be fitting. – Phizes Jul 24 '15 at 23:10
  • 1
    @SamuelEdwinWard Ubuntu does not have one set by default, but it is not prevented. Preventing a user with full root access from setting a root password would require something restricting root's privileges. Users can be given limited access to what they can do as root via sudo, see man sudo. – Phizes Jul 24 '15 at 23:16
  • 3
    @JoshTheGeek (off-topic) that's meld. – Léo Lam Jul 25 '15 at 06:40
  • 2
    @Erathiel - you don't have to distribute a shared password to use a root account. That's what PAM is for. And even without it, that's what groups are for. – mikeserv Jul 25 '15 at 14:52
  • 2
    @mikeserv You're right, there are options, as is always the case with *NIX. Still, sudo gets the job done in probably the cleanest way. – Erathiel Jul 25 '15 at 14:57
  • 1
    @Erathiel - that's completely incorrect. sudo is insane - it always has been. It accepts shell globs to identify users! And PAM is way more secure. – mikeserv Jul 25 '15 at 15:04
  • 4
    What about sudo bash (or the shell of your choice)? have you matched differencies with the rest of the commands? It should match better with sudo -i shouldn't it? – YoMismo Jul 29 '15 at 10:35
  • 1
    @YoMismo the environments (as reported by env) of sudo -s (which runs $SHELL as root) and sudo bash are 100% identical. – terdon Jul 29 '15 at 11:05
  • 2
    I assume you're only asking about cases where you want to become the root user, correct? sudo su is extremely useful for becoming a non-root user. – Kyle Strand Dec 15 '15 at 23:09
  • 3
    @KyleStrand yes, this was more about root but there's even less of a reason to ever do sudo su user. Just do sudo -iu user instead. – terdon Dec 16 '15 at 12:28
  • 1
    @terdon Huh, I was unaware of the -u flag for sudo. Semantically, though, I still prefer sudo su -- "as a super user (su-), run (-do) a single command: switch users (su)." Plus it's simpler to type on a standard QWERTY keyboard. – Kyle Strand Dec 16 '15 at 21:04
  • dhag's selected answer says: sudo -s reads .bashrc of the calling user. That conflicts with the terdon's answer which says sudo -s reads /root/.bashrc. Which is it? – gwideman Sep 05 '18 at 01:11
  • I would never do it, but if you are 100% sure that you will never have code on your system that calls su then i would just remove it. Reason: security. More programs with with SUID rights means more attack vectors. – Garo Apr 07 '21 at 11:22

2 Answers2

76

As you stated in your question, the main difference is the environment.

sudo su - vs. sudo -i

In case of sudo su - it is a login shell, so /etc/profile, .profile and .bashrc are executed and you will find yourself in root's home directory with root's environment.

sudo -i is nearly the same as sudo su - The -i (simulate initial login) option runs the shell specified by the password database entry of the target user as a login shell. This means that login-specific resource files such as .profile, .bashrc or .login will be read and executed by the shell.

sudo su vs. sudo -s

sudo su calls sudo with the command su. Bash is called as interactive non-login shell. So bash only executes .bashrc. You can see that after switching to root you are still in the same directory:

user@host:~$ sudo su
root@host:/home/user#

sudo -s reads the $SHELL variable and executes the content. If $SHELL contains /bin/bash it invokes sudo /bin/bash, which means that /bin/bash is started as non-login shell, so all the dot-files are not executed, but bash itself reads .bashrc of the calling user. Your environment stays the same. Your home will not be root's home. So you are root, but in the environment of the calling user.

Conclusion

The -i flag was added to sudo in 2004, to provide a similar function to sudo su -, so sudo su - was the template for sudo -i and meant to work like it. I think it doesn't really matter which you use, unless the environment isn't important.

Addition

A basic point that must be mentioned here is that sudo was designed to run only one single command with higher privileges and then drop those privileges to the original ones. It was never meant to really switch the user and leave open a root shell. Over the time, sudo was expanded with such mechanisms, because people were annoyed about why to use sudo in front of every command.

So the meaning of sudo was abused. sudo was meant to encourage the user to minimize the use of root privileges.

What we have now, is sudo becomes more and more popular. It is integrated in nearly every well known linux distribution. The original tool to switch to another user account is su. For an old school *nix veteran such thing like sudo might seem needless. It adds complexity and behaves more likely to the mechanisms we know from Microsofts os-family, and thus is in contrary to the philosophy of simplicity of *nix systems.

I'm not really a veteran, but also in my opinion sudo was always a thorn in my side, from the time is was introduced and I always worked around the usage of sudo, if it was possible. I am most reluctant to use sudo. On all my systems, the root account is enabled. But things change, maybe the time will come, when su will be deprecated and sudo replaces su completely.

Therefore I think, it will be the best to use sudo's internal mechanisms (-s, -i) instead of relying on an old tool such as su.

chaos
  • 48,171
  • 5
    Ah, so before 2004 there was actually a reason to run sudo su then? At the time I was using distros without sudo and active root accounts so I don't know. That might explain the prevalence of the sudo su meme in the Ubuntu world. – terdon Jul 24 '15 at 18:34
  • 9
    I never knew about sudo -i or sudo -s before - I've been running UNIXes of various sorts since 1991 and for me sudo su - is just an ingrained habit at this point. – fluffy Jul 24 '15 at 20:25
  • 3
    Is sudo -s the same as sudo $SHELL then? – Samuel Edwin Ward Jul 24 '15 at 23:11
  • 1
    @fluffy that's interesting. Were these systems with no active root account? Couldn't you just run su alone? I was running RH-based systems until around 2006 and had never seen sudo in the 6 or 7 years I'd been using Linux before that.7 – terdon Jul 26 '15 at 11:38
  • 1
    @terdon These were shared systems (both Linux and otherwise) where I had sudo access but didn't have the root password. Not every Linux (or UNIX) machine is totally under the control of the person sitting at it. :) – fluffy Jul 27 '15 at 05:50
  • 4
    (Agreeing with @chaos) The reasons to use sudo su - are 1) that it works and you know exactly what it does, and 2) that you don't have to remember another option to sudo (when you already know su -) and 3) you don't have to remember which version of sudo you're working with at the moment. Why remember one more piece of trivia when what you already have works fine? Is there anything that su -i does better other than avoid a log entry? I don't use sudo su - enough to worry about that. – jrw32982 Jul 29 '15 at 04:10
  • 1
    Chaos, could you add a conclusion that takes a position about whether or not there's any point in running sudo su? The main point you seem to be making, apart from the comparison, is that no, there's no reason to run sudo su unless you are running a system whose sudo is more than 11 years old. Is that correct? – terdon Jul 29 '15 at 09:24
  • 1
    @terdon I see, in the end I was a bit rare in words =) I tried to complete my answer a bit and hope it makes things more clear. – chaos Jul 29 '15 at 10:10
  • 1
    Thanks :) And I quite agree. I used to use su all the time until I switched to Debian-based systems and discovered sudo. – terdon Jul 29 '15 at 11:07
  • 1
    "Your home will not be root's home" (for sudo -s) - I believed this too, but the env's shown in the question don't bear it out! (Nor testing). Still, if I know sudo -i is supposed to work, it seems best to avoid stacking sudo and su. – sourcejedi Jul 29 '15 at 14:01
  • 3
    I just saw the update, very nice! For the record, let me state that I too cut my *nix teeth on systems with no sudo and am very used to su. It's the combination of the two that bugs me. – terdon Sep 03 '15 at 12:30
  • terdon's highest rated answer says: sudo -s : reads /root/.bashrc, which conflicts with chaos's answer that says sudo -s reads .bashrc of the calling user. Which is it? – gwideman Sep 05 '18 at 01:12
  • @chaos sudo -s reads /root/.bashrc, the environment does not remain the same. I just tried sudo -s and then echo $HOME and got /root. The only env variable that seems to have been carried over is PATH which I explicitly export. – terdon Sep 05 '18 at 09:45
  • It [sudo] was never meant to really switch the user and leave open a root shell. I was not aware that this was possible - I have only ever used sudo in the "one command at a time" mode. Just so I'm clear, do sudo su and sudo su -, etc all create & leave open a root shell? – Seamus Aug 07 '21 at 22:39
  • @Seamus Yes they do – chaos Aug 08 '21 at 13:50
  • That would seem to defeat the purpose of sudo in the first place - but perhaps you do not agree with this? – Seamus Aug 08 '21 at 21:31
  • @Seamus This is probabily a philosophical question, but sudo was invented to execute a "command" with elevated privileges and drop them afterwards. Nobody stops you if that "command" is a shell. Btw, I use these commands in the answer myself as well. – chaos Aug 09 '21 at 07:23
  • Umm - yes, but a poorly-worded one. I'd never actually considered using sudo in that way. I can only imagine that it defeats the purpose - because, of course, I am not the author of sudo & don't actually know the purpose from a first-hand account. I have learned something here & therefore appreciate your detailed answer. – Seamus Aug 09 '21 at 08:01
  • @Seamus No, sudo -i does not defeat the purpose of sudo; the answer left out the other (and IMHO more) important purpose of sudo which is to allow easily enabling and disabling root access (whether for one command or a session) on a per-user basis. With su all users with root access must know and share the root password, which is inconvenient, and it's even more inconvenient to change it every time you want to remove a user's root access. With sudo users use their own password and a config file determines if they're allowed to do things as root. – cjs Jan 15 '23 at 07:28
22

To answer your question directly: no, there is no good reason to do this. Also, sudo su produces two log entries when one would suffice.

I've seen many people do this, and when I ask why they don't just run sudo -s, the answer is just that they don't know about the -s flag to sudo, and generally they switch after I point it out.

However, to your list of sudo -s and sudo -i, I'd like to add one more option, sudo -sE, which is kind of a replacement for su -m. sudo -sE preserves your environment including home directory. This has risks if your home directory is insecure (on NFS). But in an environment where many people use root, it saves you from having to agree on the contents of the root .bashrc file. My .bashrc contains many specializations for root, so I don't get exactly the same environment as root, but at least I get exactly the environment I want.

user3188445
  • 5,257
  • 5
    If it preserves your environment, including $HOME, that means all new files created under the home folder are owned by root, not by you. I've had this cause many hard to diagnose permission errors. – Eris Jul 25 '15 at 22:38
  • sudo -sE and then echo $HOME gives /root on CentOS 7, bash 4.2. -sE does not appear to preserve home directory as you stated. – jeremysprofile Aug 10 '18 at 21:33
  • Using LinuxMint 19 (based on Ubuntu 18.04.1), $HOME is the user's home directory, not /root. – Ethan Furman Feb 07 '20 at 18:47
  • You can determine in the sudo configuration file exactly what environment variables are preserved, set or reset with the various env_* configuration options. And these of course can be applied on a per-user basis, per-command basis, or various other ways. So there's no problem with having $HOME set or preserved, as per your preference for whatever particular command you're running. – cjs Jan 15 '23 at 07:36