Files..

Understanding the Unix /etc/passwd File

Learn how /etc/passwd stores Unix account identity data, understand all seven fields, use safe administration tools, and troubleshoot account and UID problems.

/etc/passwd is the traditional local account database on Unix-like systems. It maps human-readable user names to numeric user identifiers and records attributes such as a primary group, home directory, and login shell.

This file is usually readable by every local user. Programs need to translate numeric owners shown by the kernel into names, and many utilities must discover account attributes without granting access to password hashes. Readability does not mean the file should be writable by ordinary users.

What /etc/passwd Does—and Does Not—Do

The operating system uses a UID, or user identifier, as a numeric identity. File ownership, process ownership, and many permission checks use the UID rather than the name typed at a prompt. An entry in /etc/passwd associates that UID with a user name and other account attributes.

The file is primarily identity and login-attribute data, not a complete authentication database. Historically, password hashes were stored in its second field. Modern systems normally place a marker such as x in that field and store password hashes and password-aging information in the protected /etc/shadow file.

In other words, identity data answers “Which account is UID 1001?” Credential data answers “Can this authentication attempt prove control of the account?” Keeping those roles separate lets ordinary software read account names without exposing password hashes.

Line Structure

Each non-comment line normally represents one account. The fields are separated by colons, producing this seven-field layout:

name:password-marker:UID:primary-GID:GECOS:home-directory:login-shell

Field values must not contain an unescaped colon because the colon is the delimiter. A blank line or a line beginning with a comment marker may be ignored by some tools, but handling can vary. Do not experiment by editing the file with an ordinary text editor; use account-management utilities, or use vipw when an exceptional direct edit is unavoidable.

The Seven Fields of /etc/passwd

Position 1 — User name: For example, alex. This is the login identity used by commands and authentication services. Names must be unique within the relevant identity source and should follow the naming rules and length limits of the operating system and site policy.

Position 2 — Password field: Commonly x when the hash is in /etc/shadow. A locked marker or another non-login marker may prevent password authentication. On legacy systems, a password hash may appear here; that arrangement is unsuitable for modern systems where the file is broadly readable.

Position 3 — UID: A decimal user identifier, such as 1001. The kernel uses it for process identity and file ownership. Changing it can require a carefully planned ownership migration.

Position 4 — Primary GID: A decimal group identifier, such as 1001. It points to the account's primary group in the group database, usually /etc/group or an NSS-provided source.

Position 5 — GECOS/comment field: Descriptive account information. A common convention is comma-separated data such as a person's full name, office location, telephone number, and other details. Applications do not all interpret every subfield identically, so avoid storing sensitive information here.

Position 6 — Home directory: The default directory for the account, such as /home/alex. A creation utility may create it, copy initial files, or leave that work to an administrator depending on options and distribution.

Position 7 — Login shell: The program started for an interactive login, commonly /bin/bash or another valid shell. A shell such as /usr/sbin/nologin or /bin/false is commonly used for service accounts that should not receive interactive sessions.

Example: A Regular User

alex:x:1001:1001:Alex Example:/home/alex:/bin/bash
  • alex is the unique account name.
  • x indicates that password verification data is normally elsewhere, such as /etc/shadow.
  • 1001 is both the UID and, in this example, the primary GID value.
  • Alex Example is descriptive GECOS data.
  • /home/alex is the home directory.
  • /bin/bash is the interactive login shell.

Common Password-Field Markers

x: The password hash is normally maintained in /etc/shadow. This is the usual modern arrangement on many Unix-like systems.

A leading lock marker: A platform may prefix the stored hash or use another marker to disable password authentication. Use passwd or the platform's supported tool instead of guessing marker semantics.

* or an invalid value: Often prevents password authentication because it cannot represent a valid password hash. Exact behavior and portability vary.

Legacy hash in the field: Older systems could store a hash directly in /etc/passwd. Because the file is commonly readable, this exposes material that should be protected; migrate to shadow passwords where supported.

Password locking is not the same as deleting an account. Locking or expiring access preserves the UID and ownership relationship, which is often important for investigation, service continuity, and file recovery.

Account Classes and UID Conventions

Root: The administrative superuser is conventionally associated with UID 0. UID 0 is privileged regardless of the account name. Unexpected additional UID 0 entries are dangerous because they can provide administrative access while appearing under a different name.

System or service account: A non-human identity used to run a daemon or application with limited privileges. It often has a dedicated home directory or a noninteractive shell. Exact UID ranges and shell paths vary by distribution and site policy.

Regular human account: An account intended for people and interactive work. It commonly has a home directory, an interactive shell, and a UID allocated from the site's regular-user range.

UID allocation ranges are conventions, not universal constants. Check local documentation and policy before assigning an identifier. The special UID and GID value 65534 is commonly associated with an unprivileged “ nobody ” or “ nobody-like ” identity when an operation cannot use the original identity, but its name and exact behavior vary by platform. Never infer privileges solely from a familiar number without checking the system.

Related Account Files and NSS

/etc/shadow: Normally stores protected password hashes and password-aging fields. It is more sensitive than /etc/passwd and should have restrictive ownership and permissions.

/etc/group: Maps group names to GIDs and commonly lists supplementary group members. The passwd entry's primary GID refers to this group database.

/etc/gshadow: Stores protected group administration information on systems that provide it.

NSS: Name Service Switch determines where account and group lookups occur and in what order. Its configuration is commonly found in /etc/nsswitch.conf.

LDAP, SSSD, and other directory services: These can supplement or replace local account lookup. Therefore, the local /etc/passwd file may not contain every account visible to commands or authentication services.

Use cat /etc/passwd to inspect local records, but use getent passwd to query the effective passwd database through NSS:

cat /etc/passwd
getent passwd
getent passwd alex
getent passwd 1001
id alex

The numeric lookup form is supported on many systems, but behavior depends on the NSS implementation. id also reports the effective UID, primary GID, and supplementary groups.

Safe Account Administration

Prefer supported tools because they coordinate related files, apply validation, preserve locking behavior, and perform distribution-specific setup.

# Create a local account; syntax and defaults vary
sudo useradd -m -s /bin/bash alex
# Some distributions provide an interactive alternative
sudo adduser alex
# Set or change a password
sudo passwd alex
# Modify selected attributes
sudo usermod -s /bin/bash alex
# Inspect or change aging and expiry settings
sudo chage -l alex
# Remove a local account only after reviewing ownership and retention policy
sudo userdel alex

Before changes, make an approved backup of relevant account data, record the current effective lookup, and confirm that you have a recovery path. If direct editing is truly necessary, vipw is preferred because it uses locking, validation, and safer editor handling. Related workflows may use a corresponding group-file editor where available.

Changing a UID or primary GID does not automatically make every existing file and service reference correct. Files may retain the old numeric owner, access-control rules may mention the old number, and a service may expect a particular group. Plan ownership migration, update references, and test before changing active production accounts.

Security and Integrity

  • The local account database should be owned by an administrative user and writable only by trusted system mechanisms. Exact modes differ by platform, but ordinary users must not be able to modify it.
  • Malformed lines, missing fields, duplicate names, invalid numeric values, and inconsistent shadow records can prevent tools or logins from working correctly.
  • Duplicate UID 0 entries require immediate investigation. A second name with UID 0 is privileged even if it looks like a normal user.
  • An unexpected interactive shell on a service account can expand attack surface. An unsafe or nonexistent shell can also cause legitimate logins to fail.
  • Lock or expire an account when access must stop but ownership and records should be preserved. Delete only after retention, evidence, and file-ownership requirements are addressed.

For auditing, compare effective entries from getent passwd with an approved inventory, review every UID 0 account, look for duplicate UIDs and names, inspect shells and home directories, and review recent account-management logs. Include directory-service identities in the audit; checking only the local file is incomplete.

Reading and Troubleshooting Entries

Unknown Numeric File Owner

If a listing shows a number instead of a name, the system could not resolve that UID at the time of display.

getent passwd 1500
cat /etc/nsswitch.conf

Possible causes include no record for the UID, an unavailable LDAP or SSSD service, an NSS source omitted from configuration, or an account deleted while its files remained. Decide whether ownership should be reassigned or retained for audit and recovery purposes; do not change it merely to make a name appear.

User Cannot Log In

  1. Query the effective record with getent passwd username, rather than assuming the local file is authoritative.
  2. Check password and account state with supported tools such as passwd and chage.
  3. Verify that the shell exists and is permitted for the login method. A noninteractive shell intentionally blocks interactive access.
  4. Check that the home directory exists and that its ownership and permissions permit the session to start.
  5. Compare local and directory-service results, then review logs appropriate to SSH, a console login, or another authentication service.

Service Fails After a UID or GID Change

Search for files still owned by the old numeric identity and inspect service configuration and access-control rules for references to the old UID or GID. Confirm that the new primary group supplies the permissions the service expects. Avoid changing identifiers on active accounts unless the migration is planned and tested.

Inconsistent passwd and shadow Data

An interrupted edit, incorrect delimiter count, invalid field, or missing corresponding shadow record can produce warnings or authentication failures. Run:

sudo pwck

Review every warning before acting. Under controlled maintenance conditions, use vipw and restore from a known-good backup when appropriate. Do not use an ordinary editor workflow that can bypass locking or leave related account files out of sync.

Unexpected Administrative Account

Audit all entries with UID 0 and compare them with the approved inventory. Investigate unexpected local accounts, privilege mappings from directory services, recent changes, and relevant logs. Disable unauthorized access according to incident-response procedures while preserving evidence.

Safe Account-Administration Workflow

  1. Confirm the requested change, affected account, identity source, and rollback plan.
  2. Back up relevant account data and record the current output of getent and id.
  3. Use useradd, adduser, usermod, userdel, passwd, or chage as appropriate.
  4. Use vipw only for an exceptional direct edit, with maintenance controls and validation.
  5. Verify the effective NSS entry, UID, primary GID, supplementary groups, shell, home directory, and password or expiry state.
  6. Check file ownership, service access, and login behavior.
  7. Document the change and audit for unexpected privileged entries or identity anomalies.

Exam-Relevant Notes

  • /etc/passwd has seven colon-separated fields.
  • The UID is the kernel-facing user identity and controls file ownership association.
  • The fourth field is the primary GID, not the complete list of group memberships.
  • The GECOS field is descriptive account data, not authentication data.
  • Modern systems normally use x in the passwd password field and protect the hash in /etc/shadow.
  • getent tests the effective NSS view; cat /etc/passwd shows only the local file.
  • UID 0 is privileged regardless of the account name.
  • vipw is safer than an ordinary editor for necessary direct passwd-file changes.
  • Changing a UID or GID can leave existing files and service configuration referencing the old number.

For a related reference, see /etc/passwd.