Users, groups and sudo

Accounts are the front door of every system. In this module you will learn where Linux keeps account data, how to manage users and groups, and how to give administrative rights without handing out the root password.

What you will learn

• The structure of /etc/passwd, /etc/shadow and /etc/group.
• Creating, locking and removing users.
• How sudo works and how to configure it safely.
• Audit checks for risky accounts and sudo rules.

Run every exercise in a lab virtual machine (for example Ubuntu Server or Debian in VirtualBox, VMware or UTM) — never on a production system or a machine you do not own.

Where accounts live

$ grep alice /etc/passwd
alice:x:1001:1001:Alice,,,:/home/alice:/bin/bash
# name : x (password is in /etc/shadow) : UID : GID : comment : home : shell

$ sudo grep alice /etc/shadow
alice:$y$j9T$...:20021:0:99999:7:::
# name : password hash : last change : min : max : warn : ...

The UID (user ID) is what the kernel actually checks. UID 0 is root — any account with UID 0 is root, whatever its name. Regular users usually start at 1000; lower numbers are system accounts for services.

Modern distributions hash passwords with yescrypt ($y$) or SHA-512 ($6$). A ! or * at the start of the hash field means password login is disabled for that account.

Managing users and groups

sudo useradd -m -s /bin/bash bob     # create user with a home directory
sudo passwd bob                      # set a password
sudo usermod -aG sudo bob            # add to the admin group (Debian/Ubuntu: sudo, RHEL/Fedora: wheel)
id bob                               # show UID, GID and groups
sudo usermod -L bob                  # lock the account
sudo chage -l bob                    # password ageing details
sudo userdel -r bob                  # remove user and home directory

Groups give a set of users shared access — for example a devs group that can write to /srv/app. Adding a user to a group takes effect at their next login.

sudo: admin rights without sharing root

sudo lets approved users run specific commands as root, using their own password, and logs every use. Rules live in /etc/sudoers and /etc/sudoers.d/. A typical rule:

%sudo   ALL=(ALL:ALL) ALL
# members of group sudo, on any host, may run any command as any user

backup  ALL=(root) NOPASSWD: /usr/local/bin/run-backup.sh
# user backup may run exactly one script as root, without a password

Risky sudo patterns

• NOPASSWD: ALL — anyone who gets that user’s session is instantly root.
• Allowing editors, pagers or interpreters (vim, less, find, python) — most can launch a root shell.
• Allowing scripts that the user can edit — they simply change the script.
• Wildcards in arguments, which often permit more than intended.

Hands-on lab

1. Create a user trainee, give them a password, and confirm with id trainee.
2. Lock the account, try to log in with su - trainee, then unlock it with usermod -U.
3. Run the audit commands below and note anything unexpected.

# Accounts with UID 0 (should be root only)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Accounts that can log in with a shell
grep -Ev '(nologin|false)$' /etc/passwd

# What may I run with sudo?
sudo -l

# Always edit sudoers with visudo (it checks syntax before saving)
sudo visudo

Check your understanding

An account called support has UID 0. Is that a problem?

Yes. UID 0 is root regardless of the name — this is a classic backdoor. Only root should have UID 0.

Why use visudo instead of editing /etc/sudoers directly?

It locks the file and checks syntax before saving. A broken sudoers file can lock every administrator out of sudo.

Why is alice ALL=(root) /usr/bin/less /var/log/* dangerous?

From inside less you can type !sh to start a shell — running as root. The wildcard also allows other files.

Key takeaways

• Only root should have UID 0; disable unused and default accounts.
• Grant admin rights through sudo and groups, never by sharing the root password.
• Keep sudo rules narrow, avoid NOPASSWD, and never allow shell-capable programs.