Linux Basics 09: Users And Groups — passwd, shadow And sudoers

What This Chapter Solves

Everyone can type the user-management commands; incidents happen in three files (passwd, shadow, group) and in one easily forgotten -a. This chapter follows the natural order — read the files, understand permissions, change accounts, then authorise — and traces a few real accidents back to their causes.

1. /etc/passwd: Seven Fields, None Of Them Guessable

grep "^$(whoami):" /etc/passwd
getent passwd "$(whoami)"

alice:x:1000:1000:Alice:/home/alice:/bin/bash
  ↑   ↑  ↑    ↑     ↑        ↑          ↑
  1   2  3    4     5        6          7

Note: do not decide “is this a system account” from the UID number alone; thresholds differ between distributions (RHEL used 500, now 1000). And getent passwd beats reading the file, because it goes through NSS and will show LDAP-provided users too.

2. /etc/shadow: ! And * Are Not The Same

sudo grep "^$(whoami):" /etc/shadow

alice:$6$xxx...:19000:0:99999:7:::
      ↑            ↑   ↑   ↑   ↑
   password hash  min  max  warn  grace

sudo awk -F: '$2 ~ /^\$/ {print $1" has a password"}' /etc/shadow | head
sudo awk -F: '$2 ~ /^!/ {print $1" locked"}' /etc/shadow | head

3. Primary Versus Supplementary Groups: Permissions Work On Sets

id                             # uid + gid + every group
id -Gn                         # group names only
getent group sudo wheel        # the admin group on Debian vs RHEL

When a process touches a file, the kernel compares permissions against the effective UID + effective GID + all supplementary groups:

• The primary group is field 4 of passwd (it becomes the group of newly created files)
• Supplementary groups are what make you “a member of” something (sudo, docker) — they are the source of privilege

Note: membership in the docker group is effectively root (you can mount host directories and run privileged containers). People treat it as a convenience; it is a privilege path.

4. Changing Accounts: Four Commands And One Guaranteed Trap

sudo useradd -m -s /bin/bash -G sudo alice     # create (-m home, -G supplementary groups)
sudo adduser bob                               # Debian's friendly wrapper: interactive, /etc/skel, password
sudo usermod -aG docker alice                  # ⭐ append a supplementary group (-a is mandatory)
sudo passwd -l alice                           # lock (prepends ! to the hash)
sudo userdel -r alice                          # delete user *and* home directory (⚠️ data goes too)
sudo chage -l alice                            # password ageing policy

sudo usermod -G docker alice     # ❌ alice is removed from sudo and loses admin rights
sudo usermod -aG docker alice    # ✅ append

5. su Versus sudo: Not The Same Tool

su -                     # become root with a login-like environment
su                       # become root but keep your environment and cwd
sudo -i                  # a root login shell — the better replacement for su -
sudo -u postgres psql    # run a single command as another user (common in service ops)

6. sudoers: Edit With visudo, Never By Hand

sudo visudo -f /etc/sudoers.d/deploy      # use a drop-in file, never the main one
# contents, for example:
#   deploy ALL=(root) NOPASSWD: /bin/systemctl restart nginx
#   %sudo ALL=(ALL:ALL) ALL               # group rules use a % prefix
sudo -l                                   # what am I allowed to do?

Notes:

• visudo matters because it validates the syntax before saving and replaces the file atomically — one wrong character in sudoers can lock you out of sudo entirely.
• NOPASSWD exists for unattended jobs; prefer not to use it, and when you must, pin the command to a full path instead of a broad /bin/systemctl wildcard.
• The admin group is sudo on Debian/Ubuntu and wheel on RHEL — a detail scripts get wrong when moving between families.

7. Hands-On Checklist

id; groups                                  # 1. identity and group set
getent passwd "$(whoami)"                    # 2. the seven fields
sudo awk -F: '$2 ~ /^!/ {print $1}' /etc/shadow | head   # 3. who is locked
sudo useradd -m -s /bin/bash t1; id t1       # 4. create (primary group defaults to a same-named group)
sudo usermod -aG docker t1; id -Gn t1        # 5. append a supplementary group
sudo passwd -l t1; sudo awk -F: '$1=="t1"{print substr($2,1,1)}' /etc/shadow   # 6. the "!" mark
sudo userdel -r t1                           # 7. cleanup (removes the home directory)
sudo -l                                      # 8. your sudo rights

Summary

• passwd holds identity (UID/GID/home/shell); shadow holds passwords. ! means locked, * means no password can match.
• Supplementary groups are where privilege comes from (sudo, docker); docker membership is effectively root.
• usermod -aG needs the -a; userdel -r takes the home directory with it.
• su needs the target’s password, sudo needs yours and authorises per command; the audit trail lives in /var/log/auth.log.
• Only ever edit drop-ins under /etc/sudoers.d/, and always through visudo.

Next Up

Package management: what happens between apt update and install, finding which package owns a file with dpkg -S, pinning versions (apt-mark hold and preferences), the four most common errors and their causes, and the dnf equivalents on the RHEL side.