You’ll see in most all modern Linux guides, commands that look like:
sudo apt-get updates
sudo command stands for the old phrase “superuser do” – it basically tells the shell to the run the following command AS-IF it were the superuser; “root” in most cases.
If you tried to run this command as a normal user, you would get a lot of
permission denied errors since
apt-get (in this case) wouldn’t be able to read and write to the system-level directories it needs to.
Why does anyone use ‘sudo’?
On Linux, strict user-permission management is why it has been such a successful OS in the server space and been a secure choice for running world-critical operations for so long.
If you remember the legacy Window days (Windows 3.x, 95/98, Vista) – you’ll remember that ANY account you created on that Windows machines – for you, your sister, your aunt, your neighbor – could do anything they wanted to the box once they had logged in… even erase the
C:\Windows directory if they wanted to.
This made no sense, why did these unimportant accounts have so much control over a computer they were merely a guest on?
Well that was an example of horrific user-permission management and the problems it can present.
Linux, on the other hand, excels at this separation of roles and permissions by typically having a handful of “users” (not real people-users, but more like roles) pre-defined on a stock Linux system and then giving those “users” locked down and limited permissions so even if they wanted to be nefarious or became compromised, they couldn’t do much.
On your own brand new install, you can check this out by spitting the contents of the
/etc/passwd file to the terminal, like so:
On a default Ubuntu 20.04 install I had laying around, this was the list of accounts defined in the
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin ... 20 more lines of accounts ...
At first blush this might seem like a LOT of accounts to have on a brand new system – but as mentioned, these accounts are narrowly defined to very special roles and given very limited permissions to do anything BUT that role.
For example, inability for certain accounts to even login to a command line, certain group assignments that limit them to reading/writing certain directories, etc.
This kind of limitation goes for YOUR user account as well – your non-root user account has very limited permissions to read and write to directories outside of your home user directory (easily referenced by the
~ variable from the command line, e.g.
In order to be able to run commands using
sudo from your account, you need to make sure your account is added to what Linux calls the
sudoers list; it is just what it sounds like – the list of accounts the system allows to utilize sudo.
While it might seem unsafe to anoint yourself with root-like privileges by adding it to the sudoers list, the alternative of constantly logging in as root and performing all operations from there is much more dangerous.
While it’s technically fine to add yourself directly to the
/etc/sudoers list or more preferably, add a new file to the
/etc/sudoers.d directory with the preferred permissions, it’s much easier to use the
adduser command to add the
sudo group to your user.
Check we even need to do this…
Before starting, you might double-check your account isn’t already in the
sudo group – a number of distros do this automatically during setup.
You can check this by typing the
groups command directly into the terminal when logged in, it will echo to the terminal all the groups your current user is in, like so:
$ groups rkalla adm cdrom dip plugdev lpadmin sambashare
Hmm, I don’t see
sudo anywhere in there – so we need to fix that.
If you do see
sudo in that list, you are done and can skip the rest of this section.
Adding your user to the sudo group
root – this is one of the few times you’ll need to do this because remember, the user you are logged in as now doesn’t have the ability to run commands as
usermod -a -G sudo some-user-name
Where you would replace the entirety of “some-user-name” with your account username – in my case, it was “rkalla” so my command looked like:
usermod -a -G sudo rkalla
To break the command down a bit, we have:
usermodis the command user to modify user accounts – in this case the modification is adding a user account to the ‘sudo’ group.
-aused to specify we are adding the user to the group
-Ga coma-separated list of group names to add the user to.
Good job, your user account should be in the
sudo group and ready to use now!
Let’s do one more thing to verify the change…
Verifying our work
Log out of root and fall back into your user account shell by pressing
CTRL-D. or typing
Now that you are back in the context of your user accounts shell (and not
root‘s), you can check the groups your user is in to make sure
sudo is in there using the command we used above:
$ groups rkalla adm cdrom dip plugdev lpadmin sambashare sudo
Excellent, there it is right at the end!
Now we are ready to start issuing commands from this user account without constantly staying logged in as
Now that your user-account is enabled for root-like execution, you can do things like lock down access on your machine to the
Before wrapping up, let’s logout of
root terminal session and fall back up into your user account by pressing
CTRL-D or typing
logout in the terminal.