Users, Groups, and Ownership

In one line

Every file on Linux has exactly one owning USER and one owning GROUP — understanding those two facts is the foundation the entire permissions system (next topic) is built on top of.

0/7 · 0%

Think of it like this

A shared apartment. Each room has one PRIMARY tenant (the owning user) and belongs to one HOUSEHOLD (the owning group) — a roommate not in that household needs explicit permission to enter, exactly like a Linux user outside a file's owning group needs explicit 'other' permissions (next topic) to access it.

Key ideas

01
whoami prints your current username. id prints far more: your user ID (UID), your primary group ID (GID), and every SECONDARY group you belong to — genuinely useful when debugging 'why can't this user access that file' questions.
02
Every user has exactly one PRIMARY group (usually a group created just for them, matching their username) but can belong to any number of SECONDARY groups — being added to the docker group (a very common real setup, covered in Docker's own course) is a secondary-group membership, not a change to your primary group.
03
root is the Linux superuser — UID 0, with permission to do essentially ANYTHING on the system, bypassing normal permission checks entirely. Modern practice strongly avoids logging in AS root directly; instead, sudo <command> runs a SINGLE command with root privileges, then immediately returns you to your normal, restricted user — a far smaller blast radius for any mistake.
04
chown <user>:<group> <file> changes a file's owning user and group (requires root/sudo to change to a DIFFERENT user, but you generally can change the group to any group you're already a member of). chgrp <group> <file> changes just the group, more narrowly.
05
/etc/passwd lists every user account on the system (despite the name, it hasn't stored actual passwords in plaintext for decades — those live hashed in /etc/shadow, readable only by root); /etc/group lists every group and its members — both are just plain text files, directly cat-able.

Code & diagrams

users-and-ownership.shmarkdown

Read-only exploration commands — safe to run on any machine.

# Who am I, and what groups am I in?
whoami
id

# See every user on the system (names only, for readability)
cut -d: -f1 /etc/passwd

# See every group and its members
cat /etc/group | head -10

# Check who owns a specific file
ls -l /etc/passwd

# Change a file's owner (needs sudo to change to ANOTHER user)
touch myfile.txt
sudo chown root:root myfile.txt
ls -l myfile.txt
# (change it back to yourself afterward)
sudo chown $(whoami):$(whoami) myfile.txt

Explain it without notes

Why does modern practice prefer sudo over logging in directly as the root user?

What's the practical difference between a user's PRIMARY group and their SECONDARY group memberships?

Practice

Run id on your own account and identify your UID, your primary GID, and list every secondary group you belong to.

Create a test file and use ls -l to identify its owning user and group, then use chgrp to change just the group (to any group you're already a member of) and confirm the change with ls -l again.

Trade-offs

↔
Requiring sudo for every privileged action adds a small amount of typing friction compared to just staying logged in as root — a genuinely worthwhile trade given how much safer it makes routine work, which is exactly why virtually every modern Linux distribution defaults to this model instead of encouraging root logins.

Done when you can

I can use whoami and id to inspect my own user and group memberships.
I understand the difference between a primary group and secondary group memberships.
I understand why sudo is preferred over logging in as root directly.