Local Users, Groups, and Identity Files

1. Linux identity is numeric

Linux displays names because names are convenient for people, but the kernel makes access-control decisions with numbers. A user is represented by a user ID, or UID; a group is represented by a group ID, or GID. Files store numeric owners, processes carry numeric credentials, and permission checks compare those values. The mapping from a name such as deploy to a UID such as 1002 is a user-space lookup.

This distinction becomes visible after restoring files from another machine, mounting shared storage, or running containers with host-mounted volumes. If UID 1002 belongs to deploy on one host but analyst on another, the kernel still sees 1002. Names can therefore look correct while numeric ownership is wrong—or names may be missing while access still follows the stored numbers.

2. From a name to an authorization decision

Applications commonly call the system C library to resolve a name. The Name Service Switch configuration decides whether the answer comes from local files, systemd-resolved components, LDAP, Active Directory integration, SSSD, or another configured source. The resulting numeric credentials are then used by the process and kernel.

flowchart TD
  N["User or service name"] --> L["NSS-aware library lookup"]
  C["/etc/nsswitch.conf"] --> L
  L --> F["Local files"]
  L --> R["Directory or remote identity source"]
  F --> I["UID, primary GID, supplementary groups"]
  R --> I
  I --> P["Process credentials"]
  P --> K["Kernel authorization checks"]

3. Local identity databases

The traditional local databases are line-oriented text files. They are not all equally sensitive. /etc/passwd must be readable so programs can map UIDs to names; modern systems place password hashes and aging data in root-readable /etc/shadow.

An x in the password field of /etc/passwd means that the password verifier is stored elsewhere, normally in /etc/shadow. It does not mean the account's password is literally “x.” Never copy shadow content into tickets, chat, course submissions, or diagnostic bundles.

4. Process credentials and group membership

A login program authenticates a user, establishes account policy, initializes the primary and supplementary groups, and starts a session. Child processes inherit those credentials unless a privileged mechanism changes them. The shell's current group list is therefore a property of the running session, not a live query performed before every file access.

This explains a common troubleshooting surprise: after an administrator adds your account to a group, an already-running terminal may not receive that group. Start a new login session, use an approved session-refresh mechanism, or inspect the exact process before assuming the group change failed.

# Compare the current shell's identity views
whoami
id
id -u
id -g
id -G
id -nG

# Inspect numeric and named credentials on the shell process
ps -o pid,ppid,user,uid,group,gid,comm -p $$

# Resolve accounts and groups through the configured NSS stack
getent passwd "$USER"
getent group "$(id -gn)"
getent passwd 0
getent group 0

5. Safe identity inspection patterns

Prefer tools that understand account syntax and configured identity sources. getent is generally safer than improvised parsing for lookups. When auditing local files, select only the fields needed and preserve numeric values so duplicate or unexpected IDs are visible.

# List local account names, UIDs, primary GIDs, homes, and shells
awk -F: '{printf "%-24s uid=%-6s gid=%-6s home=%-28s shell=%s\n", $1,$3,$4,$6,$7}' /etc/passwd

# Show duplicate local UIDs, if any
cut -d: -f3 /etc/passwd | sort -n | uniq -d

# Show supplementary groups for a named account through NSS
account=${USER:?USER is not set}
id "$account"

# Compare a file's numeric and named ownership
probe=$HOME
stat -c 'path=%n owner=%U(%u) group=%G(%g) mode=%A' "$probe"

System accounts often use low UIDs, but the exact ranges come from distribution policy and local configuration. Do not delete an account simply because it has a non-interactive shell or a low UID; package-managed services rely on such identities.

6. Hands-on lab: build a non-sensitive identity inventory

This lab is read-only and does not require sudo. It records the configured lookup order, current credentials, selected account metadata, and ownership of your course directory. It intentionally excludes shadow databases.

lab="$HOME/devops-academy/linux/chapter07/lesson01"
mkdir -p "$lab"
report="$lab/identity-inventory.txt"

{
  printf '=== generated ===\n'
  date -Is

  printf '\n=== current process identity ===\n'
  id
  ps -o pid,ppid,user,uid,group,gid,comm -p $$

  printf '\n=== NSS configuration ===\n'
  grep -E '^(passwd|group|shadow):' /etc/nsswitch.conf 2>/dev/null || true

  printf '\n=== current account through NSS ===\n'
  getent passwd "$USER"

  printf '\n=== current groups through NSS ===\n'
  for group in $(id -nG); do
    getent group "$group"
  done

  printf '\n=== course directory ownership ===\n'
  stat -c 'path=%n owner=%U(%u) group=%G(%g) mode=%A' "$HOME/devops-academy"
} > "$report"

chmod 600 "$report"
less "$report"

7. Common mistakes

8. Knowledge check

9. Summary

Linux identity begins with numeric UIDs and GIDs. Local files, NSS, and optional directory services map human-readable names to those numbers; login components initialize process credentials; and the kernel uses the credentials for authorization. Reliable operations require checking the configured identity view, the exact process, and numeric ownership—not merely trusting displayed names.

10. Further reading

• Linux man-pages: passwd(5), group(5), shadow(5), and credentials(7).
• GNU C Library documentation for the Name Service Switch.
• Linux man-pages: getent(1), id(1), and nsswitch.conf(5).
• Your distribution's account and UID/GID allocation policy.