Enabling sudo for your non-root account

You’ll see in most all modern Linux guides, commands that look like:

sudo apt-get updates

The 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:

cat /etc/passwd

On a default Ubuntu 20.04 install I had laying around, this was the list of accounts defined in the passwd file:

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. cd ~)

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

Login as 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 sudo yet:

su -

Now type:

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:

  • usermod is the command user to modify user accounts – in this case the modification is adding a user account to the ‘sudo’ group.
    • -a used to specify we are adding the user to the group
    • -G a 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 logout.

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 root.

Now that your user-account is enabled for root-like execution, you can do things like lock down access on your machine to the root account.

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.