Kahibaro
Discord Login Register ☰
☰
Previous
Up
Next

3.4.1 User information files

Table of Contents

Introduction

User information on a Linux system is stored in a small set of plain text files under /etc. These files define who the users are, which groups they belong to, and how authentication is supposed to work. In this chapter you will focus on those core files, how to read them, and what role each field plays. You will not yet create or remove users in practice, that will come in the following chapters. Here you learn where the information lives and how it is structured.

The `/etc/passwd` file

Historically, /etc/passwd held all information about each user, including the actual password hash. On modern systems it still exists and is the primary index of user accounts, but the real passwords are stored somewhere else for security reasons.

You can view it with a pager or a simple command such as: 

cat /etc/passwd

Each line in this file describes a single user account. Fields are separated by colons, with exactly seven fields per line. A typical line looks like this: 

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

From left to right, the fields are:

  1. Login name
    This is the username, here alice. It is what you type at a login prompt or before the @ in ssh alice@server.
  2. Password placeholder
    Usually just x or sometimes . On modern systems this does not contain an actual password hash. Instead, it indicates that the real password entry is stored in /etc/shadow. If this field is or !, it usually means that password logins are disabled for this account, even if the account itself exists.
  3. User ID (UID)
    This is a numeric identifier for the user, here 1000. Internally, the system uses UIDs rather than names. UIDs below a certain range are typically reserved for system and service accounts. On many distributions, the first regular human user created gets UID 1000.
  4. Group ID (GID)
    This is a numeric identifier for the user’s primary group, here 1000. It refers to an entry in /etc/group. The system uses this GID to determine default group ownership of files the user creates.
  5. GECOS (user information)
    A free form field that traditionally stored the full name and some contact details. In the example, Alice Example,,, has a full name followed by empty subfields. On many systems the subfields are, in order, full name, room number, work phone, and home phone. Modern desktops often ignore most of this, but tools such as finger or chage may display it.
  6. Home directory
    The directory that becomes the user’s home when they log in, here /home/alice. Many shells use the symbol ~ to refer to this directory for the current user.
  7. Login shell
    The program that runs after login, here /bin/bash. For interactive users this is usually a shell such as bash, zsh, or fish. For system users this may be /usr/sbin/nologin or /bin/false to prevent interactive logins.

Every line in /etc/passwd must have exactly six colons and seven fields.
A malformed line can prevent logins or break tools that manage users.

For basic inspection there is a dedicated tool: 

getent passwd alice

This command does not just read /etc/passwd. It also respects other account sources configured on the system, which will be important in environments with LDAP or other centralized authentication.

The `/etc/shadow` file

Since /etc/passwd must be readable by many programs and often by all users, putting password hashes there would be insecure. Modern systems use /etc/shadow to store password hashes and some password policy information. This file is only readable by the superuser and a few specific system processes.

A typical line in /etc/shadow looks like this: 

alice:$y$j9T$...longHash...:19350:0:99999:7:::

Once again, fields are separated by colons, but here there are nine fields:

  1. Login name
    The same username as in /etc/passwd, here alice. It must match exactly or the account is inconsistent.
  2. Password hash and status
    This field contains the encrypted password hash, sometimes with a prefix that indicates the algorithm. A modern hash might start with $ for SHA-512 or $y$ for certain newer methods.
    Special values have special meanings:
    • !hash or starting with ! often indicates a locked password.
    • * can mean that the account cannot use a password at all.
    • An empty field means no password is set. That can allow logins without a password, which is very insecure unless combined with other restrictions.
  3. Last password change (days since epoch)
    This is an integer that counts days since 1 January 1970. For example, 19350 means the password was last changed on that day. You can convert these values with commands like date -d "1970-01-01 +19350 days", but in practice you will often let tools interpret them.
  4. Minimum days between changes
    The minimum number of days that must pass before the user is allowed to change the password again. A value of 0 means there is no minimum delay.
  5. Maximum days before change required
    The number of days after which the user must change the password. A large value such as 99999 often means that expiration is effectively disabled.
  6. Warning period
    How many days before the password expires that the system should start warning the user at login. For example, 7 means the user gets warnings for a week before expiration.
  7. Inactivity period
    The number of days of inactivity allowed after the password expires. After this period the account might be disabled until an administrator intervenes. An empty field means there is no special inactivity handling beyond normal expiration.
  8. Account expiration date
    A day count since 1 January 1970 after which the account itself expires. This is separate from password expiration and can be used for temporary accounts. An empty field means the account does not have a fixed expiration date.
  9. Reserved field
    Currently not used on most systems. It should usually be empty to avoid confusion.

You normally do not edit /etc/shadow directly. Instead, you use tools like passwd, chage, or user management commands that know how to manipulate these fields safely. However, understanding the layout is important when you interpret output or troubleshoot account and password issues.

/etc/shadow should only be readable by root.
If any other user can read it, all password hashes are exposed and the system is at serious risk.

The `/etc/group` file

Groups are a way to collect users and give them shared access to files and resources. The /etc/group file describes local groups and the users that belong to them, especially secondary group memberships.

You can inspect it with: 

cat /etc/group

A typical line looks like this: 

developers:x:1001:alice,bob

From left to right, the fields are:

  1. Group name
    A human readable name that you refer to in commands and configuration files, here developers.
  2. Password placeholder
    Traditionally used for group passwords but almost always just x or * on modern systems. Group passwords are rarely used today.
  3. Group ID (GID)
    The numeric identifier for the group, here 1001. This is what the kernel stores on files as group ownership, not the name.
  4. Member list
    A comma separated list of usernames that are members of this group as a supplementary group, here alice,bob.
    Note that the user’s primary group does not need to be listed here. For a user, primary group membership is defined by the GID field in /etc/passwd, while /etc/group lists additional memberships.

You can query the group database through getent as well: 

getent group developers

This is more flexible than manually reading the file, especially when the system uses external group sources.

The `/etc/gshadow` file

Just as /etc/shadow stores secure password data for users, /etc/gshadow stores secure group related information. Many systems do not use group passwords in practice, but the file may still exist and should be protected.

A typical line in /etc/gshadow might look like this: 

developers:!:alice:bob,carol

From left to right, the fields are:

  1. Group name
    The same group name as in /etc/group, here developers.
  2. Encrypted group password or status
    Often ! or * to indicate that no valid password exists. If a group password is actually configured, its hash appears here, similar in style to user password hashes.
  3. Group administrators
    A comma separated list of users who are considered administrators of this group. They can change membership with certain tools without full root access, depending on system configuration.
  4. Group members
    A comma separated list of users who are members of the group. This may overlap with or extend the member list seen in /etc/group, and tools that manage groups will keep the two files in sync.

As with /etc/shadow, you typically let system tools handle /etc/gshadow. Manual editing is possible, but small mistakes can easily lead to inconsistent group definitions.

Any mismatch between /etc/group and /etc/gshadow can lead to confusing group membership behavior.
Use group management commands rather than editing these files by hand whenever possible.

Name Service Switch and `getent`

On a simple standalone machine, user and group information comes primarily from the files described above. On larger networks it is common to use centralized sources such as LDAP, NIS, or other directory services. The Name Service Switch (NSS) configuration in /etc/nsswitch.conf controls which sources the system consults for user and group information, and in what order.

Instead of reading /etc/passwd or /etc/group directly, you can use getent to query the combined view: 

getent passwd
getent group
getent passwd alice
getent group developers

These commands respect NSS configuration, so they are the recommended way to see the effective user and group information that the system is using. Even on a machine that only uses local files, getent gives you the same data in a more flexible and future proof way.

Safely editing user information files

While these files are plain text, careless editing can break authentication for everyone. On most distributions, there are helper tools such as vipw and vigr that lock the relevant file and check for basic syntax errors before saving.

vipw edits /etc/passwd and sometimes /etc/shadow using your configured editor. vigr does the same for /etc/group and /etc/gshadow. By using these tools instead of editing the files directly, you reduce the chance of leaving them in an inconsistent state.

For routine administration you will normally use higher level commands that modify these files for you. However, when you need to inspect entries, troubleshoot, or confirm that a change took place, understanding the structure and meaning of the user information files is essential.

Previous
Up
Next

Views: 9

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro

Visitors: 4334 / 24h

Impressum / Imprint

Datenschutz / Data Policy