1. Introduction
Different ways exist for switching to a superuser shell session. Two common methods involve the use of sudo, but one also leverages the standard su.
In this tutorial, we discuss the difference between using sudo alone and involving su when elevating to a superuser shell. First, we compare equivalent calls to su with and without sudo. After that, we show how and why a single sudo call is usually the better way to elevate a shell session.
We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments.
2. sudo su – Versus su –
First, let’s disregard any sudo switches and discuss the difference between using su – alone and through sudo.
In essence, su – performs several changes:
- the current directory will become the $HOME of the superuser
- $PATH will get its value based on the superuser
- reset the shell environment
How does sudo alone change this behavior? In general, sudo adds the $SUDO_* environment. However, since su – resets that environment, we can only see the remnants of sudo in the process tree.
First, let’s use pstree to see how the process tree looks for a regular user:
$ pstree baeldung
sshd───bash───pstree
[...]
Next, we perform a sudo switch:
$ whoami
baeldung
$ sudo su -
[sudo] password for baeldung:
$ whoami
root
$ pstree baeldung
sshd───bash───sudo───su───bash───pstree
[...]
We can compare this with the simple su – call:
$ whoami
baeldung
$ su -
Password:
$ whoami
root
$ pstree baeldung
sshd───bash───su───bash───pstree
[...]
In both cases, we initially confirm the current user is baeldung via whoami. After that, we check the output of pstree after the switch to the superuser. The difference in the process tree is a single process – sudo.
Critically, the significant way sudo su – and su – differ comes down to which password we need to enter. When using sudo, we require sudoers privileges and enter the current user’s passphrase. On the other hand, without sudo, su – requires the superuser to have a password in the first place and expects that password at the Password: prompt.
3. sudo –login (sudo -i) Versus sudo su –
Similar to su –, the -i or –login flag to sudo invokes a superuser login shell.
As before, sudo su – uses one more process than sudo –login (sudo -i):
$ sudo su -
[sudo] password for baeldung:
$ pstree baeldung
sshd───bash───sudo───su───bash───pstree
[...]
$ exit
$ sudo -i
[sudo] password for baeldung:
$ pstree baeldung
sshd───bash───sudo───bash───pstree
[...]
Of course, the extra load comes from the call to su.
Also, unlike su – (and sudo su –), sudo –login preserves the $SUDO_* environment:
$ sudo -i
[sudo] password for baeldung:
$ env > /sudo-dash-i
$ exit
$ sudo su -
Password:
$ env > /sudo-su-dash
$ diff /sudo-dash-i /sudo-su-dash
2,4d1
< SUDO_GID=1001
< SUDO_COMMAND=/bin/bash
< SUDO_USER=baeldung
14d10
< SUDO_UID=1001
Here, we get both shell environments with env and preserve them in /sudo-dash-i and /sudo-su-dash. After that, we compare both. Evidently, the sudo -i (sudo –login) environment /sudo-dash-i contains several rows related to sudo, which sudo su – loses, as seen in /sudo-su-dash.
Since both calls use sudo, we don’t need to have a superuser password set.
In essence, sudo alone elevates the session, so sudo su – (needlessly) switches to root twice.
4. Summary
In this article, we discussed how three ways to elevate a session differ. First, we looked at two comparable options. After that, we showed the differences and similarities between sudo su – and sudo -i, equivalent to sudo –login.
In conclusion, while both ways can elevate a session, using sudo -i (sudo –login) is usually the faster and more straightforward approach.