@Fs

Understanding the /etc/passwd File

Learn how Unix and Linux /etc/passwd entries map names to UIDs, describe account properties, use shadow passwords, and support safe account administration.

What Is /etc/passwd?

/etc/passwd is the local account database file used by Unix-like systems. It stores identity and account attributes, including a textual login name, numeric user ID (UID), primary group ID (GID), home directory, and login shell.

The operating system and applications commonly need to translate between user names and UIDs. For example, a file owner is stored by the kernel as a numeric UID, while commands such as ls may display the corresponding name. For this reason, the file is normally readable by all users, but writable only by privileged administrators.

Modern systems generally do not store usable password hashes in this readable file. Instead, the second field commonly contains x, while protected password hashes and password-aging information are stored in /etc/shadow. Account identity data and authentication data are related, but they are not the same thing.

Location, Ownership, and Permissions

The standard local-file path is /etc/passwd. A typical installation has an owner and group of root, with permissions similar to 0644: everyone can read the file, while only root can modify it. Exact ownership, group, and mode can vary by operating system and hardening policy.

ls -l /etc/passwd

Direct editing is risky. A missing colon, an invalid numeric field, an accidental duplicate, or an incorrect file mode can prevent lookups, logins, or administrative commands from working. Prefer account-management tools. If a controlled manual edit is genuinely necessary, use vipw, which coordinates locking and provides checks appropriate to passwd-related files.

Structure of a passwd Entry

Each non-comment line normally describes one account. Fields are separated by colons, and their order is fixed. A typical human-account entry is:

alice:x:1000:1000:Alice Example,,,:/home/alice:/bin/bash

Empty fields and special values can have meaning. Their interpretation depends partly on the operating system, account-management utilities, PAM configuration, and other authentication settings. Do not infer account behavior from one field without considering the whole system.

Field 1: Login Name

The login name is the account's textual identifier, such as alice or websvc. It is not necessarily the person's display name. Naming rules vary, but administrators commonly use short names made from letters, digits, underscores, hyphens, or periods within the limits supported by the operating system and its tools.

A login name must not be confused with the GECOS full-name field. The login name is used in commands, paths, and lookups; the display name is descriptive information that may contain spaces.

Field 2: Password Data and Shadow Passwords

Historically, the second field held a password hash. Because /etc/passwd is normally readable by every user, keeping hashes there could make offline password attacks easier. Modern systems commonly put x in this field and store the protected hash in /etc/shadow, whose access is restricted.

Common values include:

• x: password information is normally maintained in shadow data.
• A lock marker such as ! or *: commonly indicates that password authentication is locked or unusable. Exact behavior varies.
• An empty field: may permit password authentication with no password on some systems, which is dangerous and often disabled by policy.
• A value such as !, *, or another non-password marker: may make password authentication unavailable, but other authentication methods could still apply.

These markers do not by themselves describe SSH access, PAM policy, account expiration, or every possible authentication method. Use passwd and other account-status tools rather than editing password fields by hand.

Field 3: UID and Operating-System Identity

A UID, or user identifier, is the numeric identity used by the kernel and file-ownership system. Files and processes carry UIDs; names are looked up later through configured identity sources.

UID 0 is the special privileged identity conventionally named root. Every passwd entry with UID 0 has root-equivalent privilege, regardless of its login name. Assigning UID 0 unintentionally is therefore a critical security error.

Regular human accounts often use a distribution-selected range such as 1000 and above. System or service accounts commonly use lower or separately managed ranges. Reserved ranges differ between Linux distributions and Unix variants, so do not assume that one numeric boundary applies everywhere.

Field 4: Primary GID and Groups

The fourth field is the account's primary GID. It identifies the group applied by default to processes and, depending on tools and configuration, to newly created files.

The passwd record does not normally list all groups to which a user belongs. Local group definitions are commonly stored in /etc/group; supplementary membership is represented by listing the user in group records. The command id combines these sources when displaying identity and group membership.

id alice

Field 5: GECOS or Comment

The fifth field is traditionally called the GECOS field. Today it is mainly used for descriptive account information. A common convention uses comma-separated subfields for full name, office location, office phone, and other contact information:

Alice Example,Room 12,555-0100,

Many commands display the first part as the user's real name or comment. Applications should treat this as descriptive data, not as a security control. Commas and escaping conventions can vary, so follow the local system's account-management tools.

Field 6: Home Directory

The home-directory field identifies the directory associated with a user's login environment. A successful interactive session commonly starts there, and programs look there for personal files such as shell startup files and application configuration.

A service account may use a directory that does not exist, such as /nonexistent, or a deliberately restricted directory. That is valid when the service does not need a personal workspace. A missing or inaccessible home directory can nevertheless cause problems for interactive users and applications that expect one.

Field 7: Login Shell

The login-shell field names the program commonly started for an interactive login. Examples include /bin/bash, /bin/sh, and /bin/zsh, depending on what is installed and permitted by local policy.

Service accounts often use a non-interactive shell. Common examples are /usr/sbin/nologin and /bin/false. nologin usually provides a clear refusal message, while false exits immediately. Paths differ across platforms, so verify that the selected program exists. A shell field alone does not determine every login path; SSH configuration, PAM, expiration, and other controls also matter.

Human Accounts and System Accounts

Service accounts support least privilege: a daemon can own files and run with a distinct UID without granting a person an interactive login. UID ranges and conventions are distribution-dependent.

Safe Inspection and Lookup

To view only local records, an administrator can use:

sudo cat /etc/passwd

A name-specific local-file check avoids matching unrelated text:

grep '^alice:' /etc/passwd

However, /etc/passwd is only the local file. Systems may obtain accounts from LDAP, NIS, SSSD, or another configured source. NSS, or Name Service Switch, determines how account and group lookups consult sources. Use getent when you want the result from the configured lookup system:

getent passwd
getent passwd alice
getent passwd 1000

The first command lists records available through configured NSS sources. The second looks up a name, and the third looks up a numeric UID. A directory-service account may appear through getent even though it has no local line in /etc/passwd.

Use id to see the resolved UID, primary GID, and supplementary groups:

id alice

Safe Account Administration

For example, change a shell with an account-management command instead of changing field 7 manually:

sudo usermod -s /bin/bash alice

Verify that the shell exists and is allowed by local policy. Use sudo useradd username to create accounts and sudo passwd username to manage password data where those tools are available. Before changes, make an appropriate backup and record the intended UID, GID, home, and shell. Afterward, validate with getent, id, and an appropriate test that does not disrupt an active administrative session.

NSS, PAM, and Authentication Context

NSS controls where names, UIDs, groups, and related identity data are looked up. The file /etc/nsswitch.conf can specify the order of local files and services such as LDAP, NIS, or SSSD. Consequently, a system's complete account view may not be contained in /etc/passwd.

PAM, or Pluggable Authentication Modules, provides a framework for authentication-related policy. Authentication may also depend on /etc/shadow, password aging, directory services, SSH settings, account expiration, access rules, and service-specific configuration. A visible passwd entry proves that an identity record resolved; it does not prove that the account can authenticate interactively.

Security and Operational Cautions

• Never assign UID 0 accidentally. Every UID-0 entry is privileged.
• Do not create duplicate login names or duplicate UIDs unless the consequences are deliberately understood and supported. Duplicate UIDs can make ownership ambiguous, while duplicate names can make lookups surprising.
• Do not leave /etc/passwd or related account files writable by untrusted users or processes.
• Check unexpected changes to shells, home directories, UIDs, GIDs, ownership, and permissions. A changed shell can enable or prevent access; a changed home directory can redirect configuration and sensitive files.
• Never treat a readable passwd line as proof of successful login capability.
• Do not expose or copy password hashes from protected files unnecessarily.
• Use validated tools instead of unrestricted editors, and keep a recovery path before ending the administrative session.

Troubleshooting Common Problems

The account is missing from /etc/passwd

The account may be supplied by LDAP, NIS, SSSD, or another NSS source. Run getent passwd username, then review the passwd source order in /etc/nsswitch.conf and the relevant directory-service client status. If getent also fails, investigate name-service connectivity and configuration.

The account cannot log in despite having an entry

Inspect the shell and home-directory fields. The password may be locked, missing, expired, or invalid; the shell may be nologin or false; PAM, SSH policy, account expiration, or another access control may block access. Use appropriate privileged status tools and authentication logs, taking care not to expose password hashes.

Files show a numeric owner

The file's UID has no currently available name mapping. Record the UID from file metadata and run getent passwd UID. The account may have been deleted, a directory service may be unavailable, or NSS configuration may be failing.

Account tools report a duplicate name or UID

Check both local records and getent results. A centrally supplied account may conflict with local planning, or a previous edit may have created inconsistent data. Review passwd and group mappings before choosing another UID or GID, and use validation tools or vipw rather than an unrestricted editor.

A manual edit breaks lookups or logins

The line may have the wrong number of colon-separated fields, an invalid numeric identifier, an invalid path, or incorrect ownership and permissions. Restore a known-good backup when appropriate, then verify file metadata and lookup behavior with getent and id. Use vipw for any necessary controlled edit.

Exam-Relevant Summary

• /etc/passwd is normally readable account identity data, not the modern protected password-hash store.
• Every entry has seven colon-separated fields: name, password marker, UID, primary GID, GECOS/comment, home directory, and login shell.
• UID 0 means root-equivalent privilege, regardless of the account name.
• The primary GID is one group; supplementary groups are generally resolved from group data.
• getent passwd is usually more complete than reading the local file when NSS sources are configured.
• /etc/passwd alone does not determine whether interactive authentication succeeds.
• Use useradd, usermod, userdel, passwd, chsh, chfn, and, when necessary, vipw rather than casually editing account files.