Users, Groups and sudo

Every process and file on a Linux system belongs to a user, and users are organized into groups that grant shared access. Understanding this model—and the sudo command that lets ordinary users borrow administrator power safely—is the difference between guessing at server errors and actually fixing them.

Users and the root Account

Linux identifies each user by a numeric UID and a name. Two kinds matter:

root (UID 0) – the superuser; can do anything, including destroy the system
regular users – limited to their own files and shared areas

There are also system users like www-data, mysql and nobody: they never log in, but services run under them so a hacked web server cannot read the database files. See who you are:

bash

whoami        # your username
id            # your UID, primary group and all group memberships
# uid=1000(sam) gid=1000(sam) groups=1000(sam),27(sudo),998(docker)

User accounts are recorded in /etc/passwd (world-readable, no passwords despite the name); password hashes live in root-only /etc/shadow.

Groups: Shared Access Made Simple

A group is just a named list of users. Give a file the group developers with group read/write, and every member can collaborate on it without opening it to the whole machine. Common groups you will meet:

sudo (Debian/Ubuntu) or wheel (Fedora/RHEL) – members may use sudo
docker – may control the Docker daemon
www-data – web server files

bash

groups            # which groups am I in?
getent group sudo # who is in the sudo group?

sudo: Administrator Power on Demand

Logging in as root for everyday work is dangerous—one typo can be fatal, and there is no audit trail. Instead, sudo (superuser do) runs a single command as root, after confirming your own password:

bash

sudo apt update                    # run one command as root
sudo systemctl restart nginx       # manage services
sudo -i                            # full root shell (use sparingly)
sudo !!                            # rerun the previous command with sudo

Why sudo beats a root login:

You authenticate as yourself; every action is logged with your name (/var/log/auth.log).
Power lasts one command, not a whole session (with a short cached grace period).
Access is revocable per user via the /etc/sudoers file—edited only with visudo, which checks syntax before saving and prevents locking yourself out.

If you see sam is not in the sudoers file, an administrator must add you: usermod -aG sudo sam.

Managing Users and Groups

These commands need root, so prefix them with sudo:

bash

sudo adduser alice                 # create user + home directory (interactive)
sudo passwd alice                  # set or reset her password
sudo addgroup developers           # create a group
sudo usermod -aG developers alice  # add alice to the group
sudo deluser alice                 # remove the account

The -aG pair matters: -a means append. Forgetting it (usermod -G) replaces all of the user’s supplementary groups with the list you gave—a classic way to accidentally remove someone from sudo. Group changes take effect at next login (or after newgrp developers).

Switching Users with su

bash

su - alice        # become alice (needs her password)
sudo su - www-data -s /bin/bash   # become a service user for debugging
exit              # return to your own shell

The - gives you the target user’s full login environment, which avoids subtle PATH bugs.

Practice Session

bash

whoami
id
groups
sudo whoami        # should print: root
getent group sudo

If sudo whoami prints root, you have administrator rights on this machine—use them deliberately.

Key Takeaways

root (UID 0) is all-powerful; daily work happens as a regular user.
Groups grant shared access; id and groups show your memberships.
sudo runs one command as root with logging; configure it via visudo only.
usermod -aG group user adds group membership—never forget the -a.
Service accounts like www-data isolate damage if a service is compromised.

Next lesson: Searching: grep, find and wildcards — locate anything on your system in seconds.