Media..

Understanding the Linux /etc/passwd File

Learn the purpose, seven-field format, permissions, account types, safe administration tools, NSS lookups, and validation of the Linux /etc/passwd file.

The /etc/passwd file is a local Unix account database. It maps account names to numeric identities and stores each account's basic login profile. Linux and other Unix-like systems use this information when displaying file ownership, resolving users, starting sessions, and running services.

This file is normally readable by every local user because many programs need to translate a username into a UID, or a UID into a username. Modern systems generally do not store password hashes directly in this file. Instead, password data is kept in the more restricted /etc/shadow file.

Location, ownership, and permissions

The standard path is /etc/passwd. A typical local installation has the file owned by root and uses mode 0644:

ls -l /etc/passwd
-rw-r--r-- 1 root root ... /etc/passwd

Mode 0644 means that the owner can read and write, while the group and other users can read. Ordinary users need read access for routine name and UID lookups, but they must not be able to modify account records. The exact ownership and mode can vary by operating system, hardening policy, or packaging, so treat the displayed values as typical rather than universal.

Direct, unmanaged editing can introduce malformed records, duplicate identities, invalid shells, or mismatched groups. Such errors can prevent logins or disrupt services. Use supported account-management tools and suitable administrative controls. If direct editing is unavoidable, use vipw, make a protected backup first, and validate the result.

The seven-field record format

Each nonempty line normally represents one account. The fields are separated by literal colons. A colon is therefore a delimiter and cannot normally appear as ordinary field content without breaking the record format.

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

Understanding each field

Login name

The login name is the human-readable account identifier used during authentication and in ownership displays. Local policies commonly use lowercase names, short identifiers, and a consistent convention such as a first name, an initial plus surname, or a service-specific name. The permitted character set and length depend on the platform and local tools.

Do not assume every account is a person. Human accounts usually need interactive access, while service accounts exist so a daemon can run with a distinct UID and limited permissions.

Password field and shadow passwords

Common values include:

An account's ability to authenticate can also depend on lock state, password aging, PAM policy, SSH configuration, authorized keys, the login service, and the assigned shell. Never infer complete account security from the second field alone.

UID and primary GID

A UID, or user ID, is the numeric identity the kernel uses for file ownership and permission checks. A GID, or group ID, identifies the account's primary group. File ownership is fundamentally numeric even when tools display names.

UID 0 has special importance: the account mapped to UID 0 traditionally has unrestricted administrative authority and is commonly named root. Any unexpected additional account with UID 0 is a security concern and should be investigated. Do not assume that every distribution or organization uses the same UID ranges. System-account and regular-user ranges differ by distribution and site policy.

The primary GID in /etc/passwd is not the user's complete group membership. Supplementary groups are commonly recorded in /etc/group and may also be supplied by external identity services.

GECOS or comment field

The GECOS field is optional descriptive account information. Traditional comma-separated conventions may contain a full name, office location, work telephone number, and home telephone number. For example:

Alice Example,Room 12,555-0100,555-0199

These subfields are conventions rather than a universally enforced schema. Tools such as finger, where installed and enabled, may display this information. Because it can contain personal data, protect backups and exports appropriately.

Home directory

The home-directory field states the path intended for the account's personal files and configuration. Declaring /home/alice does not create that directory, populate it, or assign correct ownership. Account-creation tools can perform those steps when requested.

Service accounts may use a directory such as /var/lib/service, a deliberately restricted path, or a nonexistent home path. The correct choice depends on what the service needs.

Login shell

The final field identifies the program normally launched for an interactive login session. Common shells include /bin/bash, /bin/sh, /bin/zsh, and /bin/fish. On some systems these paths may be implemented through different filesystem layouts.

Accounts that should not receive a normal interactive shell often use /usr/sbin/nologin or /bin/false. The list of approved shells is commonly available in /etc/shells, but whether it is enforced depends on the login service and PAM configuration.

Account categories

A privileged administrative record commonly has UID 0 and the root account name. An ordinary record might be the fabricated example alice:x:1001:1001:Alice Example,,,:/home/alice:/bin/bash. A service record could resemble websvc:x:...:...:Web service:/var/lib/websvc:/usr/sbin/nologin. Exact names, IDs, and ranges vary; never identify an account category solely by its name.

Safe inspection and administration

Read-only inspection

cat /etc/passwd
getent passwd
getent passwd USERNAME
awk -F: '{print $1, $3, $7}' /etc/passwd
awk -F: '$3 == 0 {print $1 ":" $3}' /etc/passwd
id USERNAME
getent group GROUPNAME

cat and the awk examples inspect the literal local file. getent queries the system's configured name-service sources, and id reports resolved primary and supplementary group information. The UID 0 query is a useful local-file audit; unexpected results require investigation rather than immediate deletion.

Preferred change tools

sudo useradd -m -s /bin/bash -c 'Alice Example' alice
sudo usermod -s /usr/sbin/nologin SERVICE_ACCOUNT
sudo vipw

Exact defaults and options vary by distribution. Before changing an existing service account, determine whether applications depend on its UID, GID, home path, or shell. Back up account databases securely, because backups can expose identity metadata and, in the case of shadow files, password hashes.

Related files and name service lookup

NSS, or Name Service Switch, is the framework used to look up users and groups from configured sources. The configuration in /etc/nsswitch.conf can combine local files with directory services such as LDAP or other identity providers.

passwd: files systemd ldap

The exact configuration differs by system. Consequently, an identity returned by getent passwd does not necessarily appear literally in /etc/passwd. It may come from an external source selected by NSS.

Validation, maintenance, and security

The pwck utility checks consistency between passwd-related account files. A read-only check can be run with:

sudo pwck -r

Depending on the implementation and options, checks may identify malformed records, incorrect field structure, duplicate UIDs, missing home directories, invalid shells, missing primary groups, and inconsistencies with shadow data. A warning is a prompt to investigate, not an instruction to make an unreviewed change.

• Keep protected backups before account maintenance, and limit who can read them.
• Use least privilege: grant administrative access only to approved operators and tools.
• Review duplicate UIDs and especially every unexpected UID 0 record.
• Check that home directories, shells, primary groups, and service paths still exist and have suitable ownership and permissions.
• Remember that numeric ownership persists even if an account is renamed or deleted.
• After changes, test the intended login or service behavior and review relevant authentication or service logs.

Troubleshooting common problems

A name is absent from /etc/passwd but works with getent

This usually means NSS is consulting an external directory or another configured source. Compare the local file with getent passwd USERNAME and inspect the passwd line in /etc/nsswitch.conf. Do not add a duplicate local record without understanding the lookup order.

A new user cannot log in interactively

Check the passwd record, account lock state, password availability, shell path, and home-directory existence and ownership. A shell set to nologin or false, an unavailable executable, PAM or SSH policy, or unsuitable home permissions can all prevent a session. Relevant authentication logs often provide the decisive detail.

A service fails after its account was changed

Review the service configuration, current numeric file ownership, UID, GID, home path, shell, and system logs. Changing or reusing a UID can make existing files appear to belong to a different account. A deleted account can also leave files owned only by a numeric ID.

ls -n /path/to/file
getent passwd NUMERIC_UID

pwck reports malformed or inconsistent entries

Make a secure backup, inspect the reported record, and determine whether a colon-separated line has the wrong number of fields, references a nonexistent GID, names an invalid shell or home path, or contains a manually introduced value. Correct the issue with a supported tool where possible, then run validation again.

An unexpected UID 0 account exists

Do not simply remove it during an active incident. Audit its origin, authentication methods, authorized access, ownership of related files, and relevant logs according to your security procedure. It may be a deliberate compatibility account, an accidental administrative account, or unauthorized persistence.

Exam-relevant notes

• /etc/passwd has seven colon-separated fields: name, password marker, UID, primary GID, GECOS, home directory, and login shell.
• UID 0 is the privileged identity traditionally associated with root.
• The second field commonly contains x because password hashes are stored in /etc/shadow.
• The primary GID is not the same as complete group membership; supplementary groups are commonly in /etc/group.
• getent uses NSS and can return identities that are not literal lines in the local file.
• Use vipw rather than an uncoordinated text editor when exceptional direct editing is required, and validate with pwck.

For a concise reference, see the /etc/passwd guide.