The /etc/passwd file lists local user accounts and basic account attributes on Unix-like systems. It is used by the system to map usernames to user IDs and shell information, while password hashes are normally stored elsewhere. Defenders should ensure it remains readable as required by the system but not writable by ordinary users, and review it for unexpected accounts or shells.
What /etc/passwd actually stores
The /etc/passwd file is the system’s local account directory, not a password store. Each line represents one account and records fields such as the username, user ID, group ID, home directory, and login shell. On modern Unix-like systems, the actual password hash is usually kept in a separate protected file or directory, while /etc/passwd remains world-readable so login and lookup functions can work.
Because the file is primarily an identity lookup table, its meaning is operational rather than secret. A typical system reads it constantly for account resolution, shell selection, and user-facing utilities. That is why the file must be readable by the right processes and users, but should never be writable by ordinary accounts.
How the system uses it during login and account lookup
When a process needs to resolve a username into a numeric identity, it reads /etc/passwd and uses the stored user ID and group ID as the authoritative local mapping. That mapping is important because many permissions checks on Unix-like systems are based on numeric IDs, not the text username itself. The shell field also matters because it tells the login system what command interpreter, if any, should start for that account.
This is why changes to /etc/passwd have immediate security and operational consequences. A new line can create a new local account, a modified shell can grant interactive access, and an altered user ID can affect which files a process can reach. If you want to review the broader Unix account database and related exposure paths, the Credential Dumping Guide is useful because it also discusses where account material and password-related artifacts are commonly found.
What defenders should watch for in practice
Administrators usually treat /etc/passwd as a baseline integrity file. Unexpected entries, unfamiliar shells, duplicated user IDs, or accounts that should have been removed are all worth investigating. On many systems, the file can also reveal whether someone has created a low-friction foothold by adding a local account rather than trying to reuse an existing one.
Its permissions matter too. The file must be readable enough for normal name-to-ID lookup, but write access should be tightly restricted to privileged administration paths. If ordinary users can modify it, the host’s local authorization model can be subverted quickly and quietly. That is why review of file ownership, mode, and recent change history is part of routine host hardening and incident response.
Risk and Threat Considerations
/etc/passwd is often treated as harmless because it is readable, but it becomes a high-value control file the moment an attacker can alter it. A malicious change can create a backdoor account, point a user at an unexpected shell, or disguise identity changes that support persistence and later privilege abuse.
Failure mechanism: Attackers abuse writable account-mapping files to introduce or alter local identities, then use the new mapping to obtain or preserve access without relying on the normal account provisioning path.
Impact: The host can gain a persistent unauthorized login path, permission checks can be distorted, and defenders may miss the change if they are only looking for password theft rather than local account tampering.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Local account entries and shells are governed by account lifecycle controls. |
| IA-2 — Identification and Authentication (Organizational Users) | passwd underpins local user identity mapping used by login and access decisions. | |
| CM-5 — Access Restrictions for Change | Unauthorized edits to /etc/passwd are a configuration integrity risk. | |
| Recommendation — Review and approve local accounts, shells, and removals under AC-2. Bind local user identities to approved authentication paths under IA-2. Restrict who can modify account files and track every change under CM-5. | ||
Practitioner Guidance
What to verify: Confirm that /etc/passwd is owned by root, writable only through trusted administrative controls, and consistent with the expected local account inventory. Review recent diffs for new accounts, shell changes, UID anomalies, and entries that should have been removed.
Common mistake: Treating /etc/passwd as the password store. The file is primarily an account index, so securing it means protecting integrity and change control, not just reading the usernames it contains.
Practitioner takeaway: The key judgment is to treat /etc/passwd as a trust anchor for local account resolution, meaning any unauthorized edit is both an identity change and a potential persistence event.