What Does /etc/passwd Mean?
This page mentions older exam versions. See the Current Exam Context and Legacy Exam Context sections below for the updated mapping.
On This Page
Quick Definition
The /etc/passwd file is a simple text file that lists every user account on a Linux or Unix system. It holds basic details like the username, user ID number, and the default shell program. While it stores some account information, it does not contain encrypted passwords in modern systems. Instead, password hashes are kept in the /etc/shadow file for better security.
Commonly Confused With
/etc/shadow stores the actual password hashes, account expiration data, and other security-related fields. /etc/passwd only contains a placeholder ('x') in the password field. /etc/shadow has stricter permissions (usually 640 or 600) and is readable only by root.
User john's /etc/passwd line shows 'x' where the password was, but his password hash 's$9jDk2S...' is stored in /etc/shadow. You must read /etc/shadow to see the hash, not /etc/passwd.
/etc/group maps group names to group IDs (GIDs) and lists group members. /etc/passwd only contains the user's primary GID but not their supplementary group memberships. The /etc/group file holds all groups and their members.
If user 'alice' is in the 'admin' group as a supplementary member, that membership is recorded in /etc/group, not in /etc/passwd. /etc/passwd only shows her primary group GID.
/etc/login.defs is a configuration file that defines system-wide defaults for user accounts, like the range of UIDs and GIDs, password aging limits, and the location of the skeleton directory. /etc/passwd does not define defaults; it holds specific account entries.
When you run useradd, it reads /etc/login.defs to know that new user UIDs should start at 1000. The actual new user's entry goes into /etc/passwd. /etc/login.defs controls the rules; /etc/passwd stores the results.
Must Know for Exams
The /etc/passwd file is a staple in many IT certification exams, including CompTIA Linux+ (XK0-005), Red Hat Certified System Administrator (RHCSA), and the Linux Professional Institute (LPI) LPIC-1 exams. In these exams, the term appears both in conceptual questions and in performance-based scenarios. You might be asked to identify the purpose of the file, its fields, or the security implications of its permissions.
For example, a typical CompTIA Linux+ objective might ask you to explain the difference between the /etc/passwd and /etc/shadow files, or to edit the /etc/passwd file to change a user's home directory or default shell. In the RHCSA exam, you will likely have to add, modify, or delete user accounts using the useradd, passwd, and usermod commands, all of which directly manipulate /etc/passwd. You might also face a question where a user cannot log in, and you need to check if the shell field in /etc/passwd is set to a valid shell like /bin/bash or if it is set to /sbin/nologin (which prevents login).
In Security+ or CASP+ exams, the file is discussed in the context of password storage and hash migration, with questions about why shadow passwords exist and how attackers might exploit a readable /etc/passwd file from a legacy system. You could also see scenario-based questions where you are given a grep command output and asked to interpret it. For instance, an exam might present the output of 'cat /etc/passwd | grep -v /bin/false' and ask what users have login access.
Understanding the field order and the meaning of each delimiter is critical for these questions. Performance-based exams might require you to edit the file directly with 'vipw' to fix a mistake-knowing that 'vipw' locks the file to prevent concurrent edits is a common exam point. Whether you are taking a Linux-specific exam or a security certification, /etc/passwd is a foundational concept that shows up regularly, and exam candidates must know its structure, security implications, and how to interact with it safely.
Simple Meaning
Think of the /etc/passwd file as the school roster for a computer that many people can use. When a new student joins the school, an administrator adds their name to the roster. The roster lists each student's full name, a student ID number, the homeroom they belong to, and what language they speak.
If the school had a system where each student was assigned a locker, the roster might also say which locker is theirs. The /etc/passwd file works the same way for a computer. It is a list of every user who is allowed to log into the system.
For each user, it records a username, a user ID number (like a student ID), the primary group they belong to, their home directory (like their locker or personal folder), and the shell program they use when they log in (like English or Spanish being the language they speak). One very important thing is that in older systems, the /etc/passwd file also stored a scrambled version of the user's password. However, because the file needs to be readable by all users on the system to look up usernames and IDs, storing passwords there was a security risk.
Modern systems have moved the actual password hashes to a separate, more secure file called /etc/shadow. Only the system administrator and some special system processes can read /etc/shadow. So /etc/passwd still holds the basic info about each user, but it shows an 'x' in the place where the password used to be, which means 'the real password is stored somewhere else.'
This separation keeps user accounts safer while still letting the system quickly look up who a user is.
Full Technical Definition
The /etc/passwd file is a colon-delimited plaintext configuration file found on all Unix and Unix-like operating systems, including Linux, BSD, and macOS. It is the primary source of local user account information and is consulted by numerous system utilities, such as login, ls, and id, to map usernames to user identifiers (UIDs) and to determine user-specific parameters. Each line in the file corresponds to a single user account and follows the format: username:password:UID:GID:comment:home_directory:shell.
The first field is the username, a case-sensitive alphanumeric string that uniquely identifies the user. The second field contains the password placeholder. In modern systems, this field holds a single 'x' character, indicating that the actual password hash is stored in the /etc/shadow file. Legacy systems without shadow passwords might have an encrypted password hash here, but this is now considered insecure. The third field is the user ID (UID), a numeric identifier used by the kernel to track users. UID 0 is reserved for the root superuser, and UIDs 1-999 (or 1-499 on some older systems) are typically reserved for system accounts. Regular user accounts usually have UIDs starting at 1000. The fourth field is the group ID (GID), which specifies the user's primary group as defined in /etc/group. The fifth field is the GECOS field, a comma-separated sub-field that can hold the user's full name, office location, work phone, and other contact information. The sixth field is the absolute path to the user's home directory, which is set as the working directory upon login. The seventh and last field is the user's login shell, the command interpreter that runs when the user logs in, such as /bin/bash, /bin/sh, or /bin/zsh.
From a system administration perspective, the /etc/passwd file must have strict permissions (typically 644, readable by all but writable only by root) because many applications need to read it for system operation. However, because the file does not contain password hashes in modern setups, its world-readability poses no critical security risk. The file is manipulated by low-level commands like useradd, usermod, and userdel, and can also be edited directly with vipw for safety. The Name Service Switch (NSS) module can configure the system to consult other sources like LDAP or NIS for user information, but the local /etc/passwd file is always checked first unless overridden. Understanding /etc/passwd is fundamental for any IT professional working with Linux, as it is central to user authentication, system auditing, and access control.
Real-Life Example
Imagine you work in a large office building with hundreds of employees. Each employee has a badge that lets them enter the building and access certain rooms. The building's main security desk has a master binder that lists every employee and their badge number.
The binder is kept at the front desk so that any security guard can look up an employee quickly. However, the binder does not contain the actual PIN code each employee uses to enter secure labs-that information is stored in a locked safe in the security manager's office. In this analogy, the master binder is the /etc/passwd file.
It holds the basic 'who is this person?' information: the employee's name (username), their employee ID number (UID), their department (GID), and their desk location (home directory). The binder also notes which type of phone system they use, like a desk phone or a mobile phone (the shell).
When a new employee joins, the HR representative adds a new page to the binder. The security guard can open the binder and verify that a person with a certain badge number exists. But if someone lost their badge and tried to claim a new one, the guard would not be able to confirm their PIN because that sensitive information is kept separately in the manager's safe (the /etc/shadow file).
So the binder is essential for day-to-day operations, but the more sensitive secrets are stored somewhere much more protected. This separation is exactly why modern /etc/passwd has an 'x' in the password field: the binder acknowledges the person exists, but the real authentication secret is elsewhere. If the office binder were stolen, a thief would get names and badge numbers but not the PIN codes, so the damage is limited.
Why This Term Matters
For IT professionals, the /etc/passwd file is at the heart of user management on Linux systems, and understanding it is essential for security, troubleshooting, and system administration. When you manage a server, you need to know who has accounts, what their privileges are, and how to control access. Misconfiguring this file can lead to serious problems, such as users being unable to log in, system services failing, or privilege escalation vulnerabilities.
One very common scenario is when a user account is accidentally deleted or its UID is changed, causing all files owned by that user to become orphaned or appear as owned by a different user. This is because the kernel tracks file ownership by UID, not username. If you delete a user and later create a new user with the same UID, that new user will suddenly own all the old user's files-which could be a security nightmare.
Another way the /etc/passwd file matters is in system auditing. When you run commands like ls -l to see file permissions, the system looks up the UID in /etc/passwd to display the username. If the file is corrupted or missing entries, you will see numeric UIDs instead of names, making it harder to manage the system.
Also, the file is critical in the context of single-user mode or recovery. If you boot into rescue mode to fix a broken system, you may need to edit /etc/passwd manually to enable the root account or fix a user's home directory. Not knowing the file format could render a system unrecoverable without a reinstall.
In short, /etc/passwd is not just a dusty old file; it is a living document that every system administrator interacts with, directly or indirectly, on a daily basis. Mastering it is a rite of passage for any Linux admin.
How It Appears in Exam Questions
In certification exams, /etc/passwd questions generally fall into three categories: conceptual understanding, configuration scenarios, and troubleshooting. Conceptual questions are often multiple-choice and test your knowledge of the file's format, purpose, and relationship to other files. For example, you might be asked: 'Which field in /etc/passwd indicates the user's primary group?'
or 'What does the 'x' in the password field of /etc/passwd signify?' These questions require you to know the seven colon-separated fields by heart. Configuration scenario questions present you with a situation where an administrator needs to set up a user account with specific parameters.
For instance, 'A new developer needs an account with a home directory of /home/dev_john and a shell of /bin/zsh. Which command or editing step accomplishes this?' You might need to recall that 'useradd -m -d /home/dev_john -s /bin/zsh john' does the job, or that you could edit /etc/passwd directly to change those fields.
Troubleshooting questions are more complex and often involve reading output or logs. A classic pattern: 'A user reports that they can log in but immediately log out. What is the likely cause?'
The answer is often that their shell is set to a non-existent or invalid program, like /bin/bash typo as 'bin/bash', or that the home directory is missing. Another common troubleshooting question: 'After running userdel -r, the system still shows a UID when listing files owned by that user. Why?'
This points to a still-existing file with that UID or a corrupted /etc/passwd. You might also see a question like: 'An administrator issues 'cat /etc/passwd | awk -F: '{print $1, $6}'' and asks what information is displayed.' The answer: usernames and home directories.
In performance-based exams, you may be asked to use vipw to fix a broken /etc/passwd line where a colon is missing. You should be prepared to spot errors like a missing home directory field or a shell that is not in /etc/shells. Essentially, exam questions test not just memorization, but the ability to apply the file's structure in real administrative tasks.
Study CompTIA Linux+
Test your understanding with exam-style practice questions.
Example Scenario
You are a junior system administrator for a small company that runs a Linux server hosting a web application. Your manager asks you to create a new user account for a contractor named Sarah, who will need to access the server to update the company website. Sarah's username should be 'sarah_dev', and she should use the bash shell.
You proceed to create the account using the useradd command: sudo useradd -m -s /bin/bash sarah_dev. This command does several things behind the scenes. It creates a home directory at /home/sarah_dev, sets the default shell to /bin/bash, and adds a new line to the /etc/passwd file.
Curious, you check the file with cat /etc/passwd | grep sarah_dev. The output looks like: sarah_dev:x:1005:1005::/home/sarah_dev:/bin/bash. You notice the empty GECOS field (the fifth field is empty) and the password field shows 'x', meaning the real password is in /etc/shadow.
After setting a password with sudo passwd sarah_dev, Sarah tests her login and everything works. Later that week, Sarah finishes her contract, and your manager asks you to remove her account. You use sudo userdel -r sarah_dev to delete the user and their home directory.
However, a few days later, a colleague reports that some files in /var/www/html are now showing a numeric UID of 1005 instead of a username. You realize that Sarah created some website files there, and because the userdel command did not reassign ownership, those files are now orphaned-still owned by UID 1005, which no longer exists in /etc/passwd. To fix this, you need to use the find command to locate all files owned by that UID and change their ownership to a new user, say the 'www-data' user.
This scenario illustrates a direct interaction with /etc/passwd: creating an entry, seeing it in the file, and then dealing with the consequences when the entry is removed. It shows why IT professionals need to plan user decommissioning carefully to avoid orphaned files and security risks.
Common Mistakes
Thinking /etc/passwd stores actual passwords
Modern systems separate password hashes into /etc/shadow for security. Keeping passwords in /etc/passwd would expose them to any user who reads the file.
Always assume the password field contains 'x' or another placeholder. Use /etc/shadow or getent shadow to check password hashes.
Editing /etc/passwd directly with a text editor instead of using vipw
Direct editing can cause file corruption, concurrent write issues, or accidental deletion of colons, making the system unusable.
Always use the 'vipw' command to edit /etc/passwd, as it locks the file and validates syntax.
Setting the shell field to a non-existent or invalid shell
If the shell binary does not exist or is not executable, the user will be unable to log in and may get kicked out immediately.
Verify the shell path exists and is listed in /etc/shells. Use chsh or usermod to change shells safely.
Confusing the user ID (UID) with the group ID (GID)
Placing a GID in the UID field or vice versa can cause permission issues and break file ownership mapping.
Remember the field order: username, password, UID, GID, comment, home directory, shell. Always double-check numeric identifiers.
Exam Trap — Don't Get Fooled
{"trap":"An exam exhibits an /etc/passwd entry with an encrypted password string in the password field and asks if this is a security risk.","why_learners_choose_it":"Many learners think that if a password string is hashed, it is safe because it is not in plaintext. They may also think older systems are acceptable."
,"how_to_avoid_it":"Even if the password is hashed, /etc/passwd is world-readable by design. Storing any password material there allows offline brute-force attacks. Modern systems use /etc/shadow which is only readable by root.
The presence of a hash in /etc/passwd is always a security risk."
Step-by-Step Breakdown
Identify the file location and purpose
The /etc/passwd file resides in the /etc directory and is the central repository for local user account information on Unix-like systems. It is consulted by the login process and many other system utilities to map usernames to numeric user IDs and retrieve user settings.
Understand the line format
Each line in /etc/passwd represents one user account and consists of seven colon-separated fields: username, password placeholder (usually 'x'), user ID, primary group ID, GECOS comment field, home directory, and login shell. Missing or extra colons can break the file.
Examine the password placeholder
The second field in modern systems contains an 'x' to indicate the password hash is stored in /etc/shadow. In legacy systems, this field might contain an encrypted string, but this is insecure because the file is world-readable.
Interpret the UID and GID fields
The user ID (UID) is the kernel's numeric identifier for the user. UID 0 is root, system accounts usually have UIDs below 1000, and regular users have UIDs starting at 1000. The GID is the primary group's numeric ID, defined in /etc/group.
Check the GECOS and home directory fields
The GECOS field stores optional user information like full name and phone number. The home directory field is the absolute path to the user's personal folder, which becomes the current directory upon login. If this path is wrong, the user may not get a proper environment.
Verify the shell field
The last field is the login shell, the command interpreter that runs for the user when they log in. Common shells include /bin/bash, /bin/sh, and /bin/zsh. If this field points to a non-existent binary, the user will be unable to log in. Setting it to /sbin/nologin prevents the user from logging in.
Apply changes safely
System administrators use the useradd, usermod, and userdel commands to modify /etc/passwd safely. For direct editing, the vipw command must be used, as it locks the file and runs syntax checks to prevent corruption.
Practical Mini-Lesson
The /etc/passwd file is more than just a list of usernames; it is a foundational component of user authentication and system identity on Linux. When you create a user with useradd, the system writes a new line to /etc/passwd, creates the home directory if requested, and sets default values from /etc/login.defs. As an administrator, you should never edit /etc/passwd with a regular text editor. The vipw command is designed for this purpose: it locks the file to prevent multiple simultaneous edits and runs a validation on the file after saving. If vipw detects a malformed line, it warns you and can roll back changes. This is crucial because if /etc/passwd becomes corrupted-for example, if a colon is missing or a shell path is wrong-users may not be able to log in, and system processes may fail.
Another practical consideration is the concept of the Name Service Switch (NSS) configured in /etc/nsswitch.conf. This file determines the order in which user information sources are consulted. For local files, the typical entry is 'passwd: files ldap' meaning the system checks /etc/passwd first, then an LDAP directory. This allows integration with centralized identity systems. When troubleshooting a user not being found, you can run 'getent passwd username' to see which source provides the entry. If 'getent' returns the correct data but the user still can't log in, the problem might be with the authentication source (like /etc/shadow) rather than /etc/passwd.
From a security perspective, you should regularly audit /etc/passwd for accounts with UID 0 (only root should have it), for accounts with empty password fields (which can allow login without a password), and for accounts with unusual shells like /bin/bash for service accounts that should not have interactive access. Tools like 'awk' or 'grep' can be used to quickly scan for such issues. For example, the command 'awk -F: ''{print $1 " " $3}' /etc/passwd' lists all usernames and their UIDs, and you can pipe it to sort to spot duplicate UIDs. Duplicate UIDs create confusion because the system sees them as the same user, potentially granting unintended access to files. Understanding these nuances of /etc/passwd is not just exam-relevant but is critical for the day-to-day management of a secure and functional Linux environment.
Memory Tip
Remember the /etc/passwd fields with 'UPUGSHS': Username, Password placeholder, UID, GID, Shell? No, H for Home directory, S for Shell. Or the phrase 'Users Passwords U Gid Home Shell'.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
XK0-006CompTIA Linux+ →Legacy Exam Context
Older materials may mention these exam versions, but learners should use the current objectives for their target exam.
XK0-005XK0-006(current version)Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
Frequently Asked Questions
What happens if I accidentally delete a line from /etc/passwd?
The corresponding user account will no longer exist. That user will be unable to log in, and any files owned by their UID will appear as owned by a numeric ID instead of a username.
Can I use a regular text editor like vim to edit /etc/passwd?
You can, but it is not recommended. The vipw command locks the file and validates the syntax after editing, which prevents corruption. Always use vipw for safety.
What does the 'x' in the password field mean?
The 'x' indicates that the real password hash is stored in the /etc/shadow file, which is readable only by root. This is the standard security practice on modern Linux systems.
Why can't I see the user's full name in /etc/passwd?
The full name is stored in the GECOS field (the fifth field). If it is empty, the user's real name was not provided during account creation. You can add or change it with the chfn command or by editing /etc/passwd.
What is the difference between /etc/passwd and /etc/shadow?
/etc/passwd stores basic user account information and is world-readable. /etc/shadow stores password hashes and account expiration data and is only readable by root. The two files work together for secure user authentication.
How do I add a new user account manually in /etc/passwd?
While possible, you should never manually add a line. Always use the useradd command to create a new user, as it correctly sets up the home directory, default shell, and other files like /etc/shadow and /etc/group.
Summary
The /etc/passwd file is a foundational component of user identity on Unix-like operating systems. It stores a list of all local user accounts with essential details: username, placeholder for password, user ID, primary group, comment field, home directory, and login shell. Although the file is world-readable, modern systems store the actual password hashes in the more restricted /etc/shadow file, using an 'x' as a placeholder in /etc/passwd. This separation is a key security best practice that every IT professional must understand.
The file is central to system administration tasks like creating, modifying, and deleting user accounts. Misconfigurations in /etc/passwd can lead to users being locked out, file ownership mismatches, or security vulnerabilities. Therefore, administrators must use the correct tools-useradd useradd, usermod, userdel, and vipw-to handle this file safely. In certification exams like CompTIA Linux+, RHCSA, and LPIC-1, /etc/passwd appears in conceptual, configuration, and troubleshooting questions. Candidates need to know the field order, the meaning of each field, and the security implications of the file's permissions.
The key takeaway for learners is to never treat /etc/passwd as just another text file. It is a critical system file that requires careful handling. Mastering /etc/passwd is not only essential for passing exams but also for performing secure and effective user management in real-world IT environments.