identities

Overview

Behind every username and group name is a number — the UID and GID — that the system actually uses. Understanding how Linux represents identity, and where account information is stored, clarifies how the whole access-control system fits together. This lesson covers identities.

Learning objectives

• Explain how UIDs and GIDs represent identity.
• Locate where account and group information is stored.
• Interpret an account's entry.

Core concept

Linux tracks identity by number, not name: usernames and group names are human-friendly labels mapped to a UID and GID. The mappings and account details live in a few key files:

• /etc/passwd — one line per user: username, UID, primary GID, home directory, and login shell (historically a password field, now an x placeholder).
• /etc/group — group names, GIDs, and their members.
• /etc/shadow — the actual hashed passwords, readable only by root.

The names you see are resolved to these numbers for every access decision.

How it works

When the kernel enforces permissions, it compares numeric UIDs/GIDs, not names — names are just a convenience layer resolved via these files. A user's /etc/passwd entry defines their identity and environment (which shell starts, which home directory). Because /etc/passwd maps identity but no longer holds passwords, it is world-readable; the sensitive hashes are isolated in the root-only /etc/shadow, separating "who exists" from "how they authenticate."

Practical example

A line in /etc/passwd reads:

alice:x:1000:1000:Alice Smith:/home/alice:/bin/bash

Fields: username alice, password placeholder x (real hash is in /etc/shadow), UID 1000, primary GID 1000, description, home /home/alice, and login shell /bin/bash. This single line fully describes Alice's identity and login environment.

Cybersecurity relevance

These files are prime enumeration targets. Reading /etc/passwd reveals every account, their UIDs (spot UID 0 accounts — any UID-0 account is effectively root), home directories, and shells (accounts with a shell like /bin/bash can log in; /usr/sbin/nologin cannot). /etc/shadow holds password hashes and is a high-value target requiring root to read — its protection is critical. Analysts routinely inspect these to understand a system's accounts and spot anomalies like unexpected UID-0 or hidden accounts.

Common mistakes

• Thinking /etc/passwd stores passwords — hashes are in the root-only /etc/shadow.
• Overlooking a second UID-0 account, which would be a hidden root-equivalent — a serious red flag.
• Ignoring the shell field, which indicates whether an account can actually log in.

Key takeaways

• Linux represents identity by numeric UID/GID; usernames and group names are labels resolved to those numbers.
• Account info lives in /etc/passwd (identity/environment, world-readable), /etc/group (groups), and /etc/shadow (root-only password hashes).
• These files are key for enumeration: they reveal accounts, UID-0 (root-equivalent) entries, home directories, and login shells.

Check your understanding

• Where are password hashes stored, and why is that separate from /etc/passwd?
• Why is an unexpected account with UID 0 a serious security concern?