Skip to content

Users, Groups, and sudo

Overview

Identity is the first control plane on a shared bastion or jump host. Get users, groups, and sudo right before permissions deep-dives.

This is Tutorial 6 in Module 4: Users & Permissions of the REBASH Academy Linux for Cloud & DevOps Engineers series — written for administrators, DevOps engineers, SREs, and platform engineers operating production Linux.

Prerequisites

  • Disk Usage and File Attributes
  • Terminal access with a regular user account (sudo where noted)

Learning Objectives

By the end of this tutorial, you will be able to:

  • Apply the core ideas of “Users, Groups, and sudo” on a real Linux host
  • Use modern tools (ip/ss, systemctl/journalctl) where they apply
  • Complete the lab under ~/rebash-linux/ with clear outputs
  • Relate this topic to Cloud, DevOps, and production operations
  • Explain the failure modes you would check first in an incident

Architecture

Linux ops work sits between humans/automation and the kernel, services, and network. This topic’s control points are shown below.

Architecture diagram for Users, Groups, and sudo

Theory

What it is

Linux identity is built from users (UID, primary group, home, shell) and groups (GID membership for shared access). Account records live in /etc/passwd with password hashes in /etc/shadow; groups in /etc/group. sudo lets a permitted user run commands as another user (usually root) according to /etc/sudoers and files under /etc/sudoers.d/. Service accounts often have locked passwords and nologin shells so they run daemons without interactive login.

Why it matters

Every privilege escalation path on a host is an identity decision. Over-broad sudo (ALL=(ALL) NOPASSWD:ALL) turns a compromised application user into root. Missing group membership breaks deploy pipelines that expect write access to shared directories. Cloud images typically grant the default login user membership of a sudo/wheel/admin group — knowing that model helps you harden bastions and audit who can become root.

How it works

id and getent passwd show the effective identity. useradd/adduser create accounts; usermod -aG appends secondary groups (the -a matters — without it you may replace the list). sudo -l lists your privileges; sudo -u runs as a named user. Always edit sudoers with visudo so a syntax error does not lock out administration. Prefer command allow-lists and group-based rules over per-human sprawl. Central identity (Lightweight Directory Access Protocol (LDAP), FreeIPA, cloud directory) may back getent on enterprise fleets; the local files still matter for break-glass accounts.

Key concepts and comparisons

Object Key fields Files
User UID, home, shell /etc/passwd, /etc/shadow
Group GID, members /etc/group
sudo rule Who, as whom, which commands /etc/sudoers.d/*
Pattern Prefer when
Login user + sudo Humans on bastions
System user nologin Application daemons
Group-based sudo Teams sharing the same allow-list

Common pitfalls

  • Using usermod -G without -a and removing the user from other groups.
  • Editing /etc/sudoers with a normal editor and introducing a syntax error.
  • Granting NOPASSWD broadly “for CI” on the same host humans use.
  • Deleting a user without checking processes, cron, and file ownership (userdel -r is destructive).
  • Assuming UID numbers match across hosts — NFS and shared storage care about numeric UIDs.

Hands-on Lab

Create a workspace for this tutorial.

mkdir -p ~/rebash-linux/lab06 && cd ~/rebash-linux/lab06

Focus: inspect id/passwd; create lab user/group; practise sudo -l

Step 1 – Identity inventory

id | tee id.txt
getent passwd "$USER"
getent group | head
sudo -n -l 2>&1 | tee sudo-l.txt || true
echo "Create users only on disposable lab VMs with sudo."

Final step – Cleanup note

# Keep ~/rebash-linux/ for later tutorials; destroy disposable cloud resources from this lab

Validation

  • Lab commands run under ~/rebash-linux/lab06/
  • You can explain each Theory bullet in your own words
  • You used modern tooling where applicable (ip/ss, systemctl/journalctl)
  • You can describe one production failure mode for this topic

Code Walkthrough

Production Linux practice for Users, Groups, and sudo always combines:

  1. Inspect before you change (status, df, ip, logs)
  2. Prefer reversible, documented changes (config management, drop-ins)
  3. Capture evidence (command output, journal snippets) for handovers
  4. Prefer systemctl/journalctl and ip/ss over legacy tools
  5. Least privilege — escalate with sudo only when required

Keep runbooks short enough to follow at 03:00. Automate the boring checks; keep humans for judgement.

Security Considerations

  • Treat host access and sudo as privileged — audit who can do what
  • Never paste secrets into shell history, tickets, or screenshots
  • Validate device names and paths before destructive disk or rm operations
  • Prefer key-based SSH and deny password auth on internet-facing hosts
  • Collect logs centrally; restrict who can read authentication and audit trails

Common Mistakes

Using legacy networking tools by default

ifconfig/netstat are missing or incomplete on modern images. Fix: use ip and ss.

Editing vendor unit files in place

Package upgrades overwrite /lib/systemd/system. Fix: systemctl edit drop-ins under /etc.

Trusting df without checking inodes and mounts

A full /var or exhausted inodes looks different from root. Fix: df -h, df -i, and findmnt.

Best Practices

  • Golden images + config as code over snowflake hosts
  • Alert on symptoms (failed units, disk, load) with runbooks attached
  • Time-sync (chrony) everywhere — logs and TLS depend on it
  • Separate OS and data volumes on Cloud VMs
  • Practise restore and rescue paths before you need them

Troubleshooting

Symptom Likely cause Fix
Permission denied Mode/owner/ACL/MAC namei -l, id, getfacl, SELinux/AppArmor logs
No route / timeout Routing, DNS, firewall ip route, dig, ss, security groups
Service won’t start Unit/config/deps systemctl status, journalctl -u, config -t
Disk full Logs, containers, deleted-open df/du, lsof +L1, rotate/expand
High load CPU, I/O wait, thrash vmstat, iostat, ps

Summary

Users, Groups, and sudo is essential for Cloud and DevOps engineers operating Linux hosts. Practise the lab until the inspection path is muscle memory, then continue the track.

Interview Questions

  1. How does this topic show up when operating Cloud VMs or Kubernetes nodes?
  2. What would you check first if this area misbehaves in production?
  3. Which modern Linux tools replace older equivalents here?
  4. What security control should accompany this capability?
  5. How would you automate verification of this topic in CI or a cron/timer job?

Sample answer — question 2

Start with blast radius and recent changes, then gather host signals (systemctl --failed, df, ip/ss, journalctl) before making changes. Fix forward with evidence, not guesswork.

References