3.2. Local Account Management

Every process runs as a user. Every file is owned by a user and a group. Every security boundary in Linux ultimately reduces to "which user is this running as and what are they allowed to do?" Account management is therefore not just administration — it's the foundation of the entire Linux security model.

💡 First Principle: Linux doesn't really know about "users" — it knows about UIDs (User IDs) and GIDs (Group IDs). Usernames are just human-readable labels mapped to UIDs in /etc/passwd. When the kernel checks if a process can access a file, it compares UIDs and GIDs, not names.

⚠️ Common Misconception: Candidates often think that deleting a user with userdel removes all their files. userdel removes the account entry from /etc/passwd and /etc/group — but files owned by that UID remain on the filesystem, now showing as a numeric UID instead of a username. Use userdel -r to also remove the home directory and mail spool.

Misconfigured accounts are one of the most common privilege escalation vectors. An account with the wrong UID, unnecessary sudo rights, or a forgotten shell enabled for a service account can give an attacker a foothold that persists through application patches.

Every privilege escalation attack ultimately exploits a misconfigured account — wrong UID, unnecessary sudo access, or a forgotten service account with an interactive shell. Getting account configuration right is foundational to everything else in the security stack.

Without correct account configuration, every security control downstream is undermined. A service account with /bin/bash as its shell can be logged into; a user in the wheel group without auditing can escalate undetected; a UID collision between two accounts creates unpredictable file ownership. Think of Linux user accounts in three tiers:

The nologin shell is the key security boundary: it prevents interactive login while still allowing file ownership and process execution.