Every process and file on Linux belongs to a user and a group, so account management is the heart of system security. In this lesson you will read the account files and manage users on your own practice VM (take a snapshot first).

Where accounts are stored

Three files describe who can use the system:

  • /etc/passwd lists every account, one per line. It is readable by everyone.
  • /etc/shadow stores password hashes and is readable only by root.
  • /etc/group lists groups and their members.

A line in /etc/passwd has seven fields separated by colons:

alex:x:1001:1001:Alex Kim:/home/alex:/bin/bash
  • alex is the username.
  • x means the password hash lives in /etc/shadow.
  • 1001 is the user ID (UID) and the next 1001 is the primary group ID.
  • Alex Kim is a comment field.
  • /home/alex is the home directory.
  • /bin/bash is the login shell.

UID 0 is the superuser. Only root should have UID 0. Normal users usually start at 1000. Service accounts such as www-data should use a shell like /usr/sbin/nologin so nobody can log in as them.

Auditing accounts

Compare the accounts on the machine with the authorized user list in your scenario README. Useful commands:

cut -d: -f1 /etc/passwd             # list all usernames
awk -F: '$3 == 0 {print $1}' /etc/passwd   # who has UID 0? should be only root
awk -F: '$3 >= 1000 {print $1}' /etc/passwd  # regular users
getent group sudo                   # who can use sudo
sudo passwd -S alex                 # password status for one user

Watch for unauthorized users, a second account with UID 0, accounts with empty passwords, and standard users who were added to the sudo or admin group but should not be administrators.

Managing users and groups

sudo adduser newuser                # create a user with a home directory
sudo deluser olduser                # remove an unauthorized user
sudo passwd alex                    # set a strong password
sudo usermod -aG sudo alex          # add alex to the sudo group
sudo gpasswd -d alex sudo           # remove alex from the sudo group
sudo usermod -L alex                # lock an account
sudo usermod -s /usr/sbin/nologin svc   # block interactive login

Always use -aG (append) with usermod. Leaving out -a replaces all of a user’s groups, which can lock out an administrator. Also remember the competition rule: do not delete or lock accounts the README says are required, and do not change the password of the account you are logged in with unless told to.

Password policy

Strong policy is part of hardening. Password aging lives in /etc/login.defs (for example PASS_MAX_DAYS 90, PASS_MIN_DAYS 7, PASS_WARN_AGE 14), and complexity rules are set in PAM files under /etc/pam.d/, often with libpam-pwquality. Edit with care and keep a second terminal open as root while testing, so a typo does not lock everyone out.

Check your understanding

Which UID belongs to the superuser?

  • 1
  • 0
  • 1000
  • 65534

Answer: 0 Any account with UID 0 has root powers, so only root should have it.

What does the x in the second field of /etc/passwd mean?

  • The account is disabled
  • The password is stored in /etc/shadow
  • The user has no password
  • The user is an administrator

Answer: The password is stored in /etc/shadow Modern systems keep hashes in the root-only shadow file instead of the world-readable passwd file.

Why use usermod -aG instead of usermod -G?

  • It runs faster
  • It appends a group instead of replacing all existing groups
  • It deletes the user
  • It locks the account

Answer: It appends a group instead of replacing all existing groups Without -a, the user is removed from every other supplementary group.

A service account such as www-data should normally have which login shell?

  • /bin/bash
  • /bin/zsh
  • /usr/sbin/nologin
  • /root

Answer: /usr/sbin/nologin Service accounts run programs and should never be used for interactive logins.

PreviousNext