The User/Group Model

Every permission check you learned in the last section hinges on one question: who is actually making this request? Behind every username you’ve typed or seen in an ls -l listing, Linux is tracking a set of structured records — who exists, what group they belong to, and how their password is verified. This chapter is about reading those records directly, before the next chapter covers actually creating and managing accounts.

Who Am I, Right Now?

Before looking at the system’s full list of users, start with the one you’re currently logged in as. Three commands answer slightly different versions of “who am I”:

whoami

Prints just your username — the simplest possible answer.

id

Prints considerably more: your user ID, your primary group, and every additional group you belong to, all in one line.

groups

Prints just the group names you belong to, without the numeric IDs id includes.

Try id now and you’ll see output shaped like this:

uid=1000(you) gid=1000(you) groups=1000(you),27(sudo),1001(developers)

That single line is a compact summary of everything the rest of this chapter explains in detail: a numeric user ID, a numeric primary group ID, and a full list of every group you’re a member of. Worth noticing already: your username and primary group often share the same name and even the same number — a default convention where each user gets their own personal group matching their username, separate from any shared team groups they also belong to.

`/etc/passwd`: The User Account Record

Every user account on the system — not just human logins, but system accounts too — has an entry in /etc/passwd. It’s a plain text file, readable by anyone, and you already have every tool needed to inspect it.

cat /etc/passwd

You’ll see a long list of lines, each following the same structure, colon-separated:

you:x:1000:1000:You Full Name:/home/you:/bin/bash

Seven fields, always in this order:

Field	Example	Meaning
Username	`you`	The login name
Password placeholder	`x`	Historically the password itself; now always `x`, meaning “see `/etc/shadow` instead”
User ID (UID)	`1000`	The numeric identity the kernel actually uses internally
Primary Group ID (GID)	`1000`	The numeric ID of this user’s primary group
Comment/full name	`You Full Name`	Optional descriptive text, often just a display name
Home directory	`/home/you`	Where this user lands on login, and what `~` expands to
Login shell	`/bin/bash`	The program launched when this user logs in

Tip

Everything Linux actually checks internally is the numeric UID, not the username — usernames are purely a human convenience layered on top. This is why permission checks, process ownership, and everything else in this course has ultimately been about numbers the whole time, even though you’ve never had to think in those terms until now.

System Accounts vs. Human Accounts

Scroll through a full /etc/passwd listing and you’ll notice most entries aren’t people at all — accounts like www-data, syslog, or daemon, each with a low UID and usually a login shell of /usr/sbin/nologin or /bin/false, meaning nobody can actually log in as that account interactively. These exist so services can run under their own dedicated identity, with their own permissions, isolated from both root and from real human users — a service compromised while running as www-data can only do whatever www-data has permission to do, not whatever root could do.

By convention, UIDs below 1000 are reserved for system accounts, while regular human users start at 1000 and count upward — which is exactly why your own UID showed up as 1000 in the id output earlier, if you were the first user created on the system.

`/etc/shadow`: Where Passwords Actually Live

The password itself isn’t in /etc/passwd — it moved to /etc/shadow decades ago, specifically because /etc/passwd needs to stay readable by everyone (plenty of ordinary tools need to look up usernames and UIDs), while password data very much shouldn’t be.

sudo cat /etc/shadow

Notice the sudo — unlike /etc/passwd, this file is only readable by root, which is the entire point of splitting it out in the first place. A line looks like this:

you:$6$randomsalt$longhashvalue...:19700:0:99999:7:::

The fields worth knowing: username, then the password’s hashed value (never the plaintext password itself — Linux never stores or even needs to know your actual password, only a way to verify a match), followed by several fields controlling password aging — when it was last changed, minimum and maximum days between changes, and warning periods before expiration.

Note

That hash isn’t reversible. There’s no command that turns the hash back into your password, by design — password verification works by hashing whatever you type at login and comparing the two hashes, never by decrypting anything.

`/etc/group`: Group Definitions

/etc/group lists every group on the system, one per line, in a similarly structured format:

cat /etc/group

developers:x:1001:you,alice,bob

Four colon-separated fields: group name, a password placeholder (rarely used in practice today), the group’s numeric GID, and a comma-separated list of members.

There’s a subtlety worth catching here: this member list is for a user’s supplementary groups, not their primary group. Your primary group — the one shown as gid in the id output earlier — is defined back in your own /etc/passwd entry, not listed here. /etc/group’s member list only shows users who belong to a group as an additional, secondary membership. This is exactly why a user can belong to several groups (as id showed with you, sudo, and developers together) while only ever having one single primary group.

Putting The Three Files Together

    flowchart LR
    A["/etc/passwd<br/>who exists, UID, primary GID, home, shell"] -.->|"password verification"| B["/etc/shadow<br/>hashed password, root-only"]
    A -->|"primary GID matches"| C["/etc/group<br/>group names, GIDs, supplementary members"]

Every permission check you learned in the last section ultimately traces back to these three files: a username resolves to a UID via /etc/passwd, that UID’s group memberships resolve via /etc/group, and a login is authenticated against the hash in /etc/shadow — all of it happening before you ever see a prompt.

What’s Next

You now know how the system records who exists and what they belong to — but only how to read that record, not change it. The next chapter covers actually creating, modifying, and removing users and groups yourself.

Last updated on August 19, 2026

Managing Users and Groups