Linux › Module 3 › Lesson 1
Users and Groups
How Linux users, groups, and /etc/passwd control access
Opening
The kernel does not know your name
Linux looks personal on a laptop, but it was designed for many people sharing one machine without reading each other's mail. Every process runs as a user. Every file has an owner. The kernel does not think in usernames — it thinks in numbers. If you skip this, chmod later will feel like magic. If you learn UID and GID now, permissions become a map instead of a riddle. Attackers who land as a low-privilege user immediately ask: who else is on this box, and which service accounts are overpowered?
1. UID and GID: identity as numbers
A user account is a username plus a numeric user ID (UID), a home directory, and a login shell. A group is a name plus a numeric group ID (GID). The kernel stores ownership as those numbers. Names exist so humans can read /etc/passwd; the permission check uses UID and GID. UID 0 is root. That account bypasses ordinary file permission checks. Regular humans usually start at UID 1000 on Debian/Ubuntu. Service accounts (www-data, mysql, nobody) sit in lower ranges so they are not treated as interactive people. If two usernames somehow shared the same UID, Linux would treat them as the same identity — a classic misconfiguration that collapses isolation.
Commands that show who you are right now:
whoami
Prints the username of the current effective identity — the name, not the full map.
id
Prints uid=, gid=, and groups=. This is the defender view: numeric IDs plus every group that grants extra access.
groups
Lists group names only. Useful, but thinner than id when you need GIDs.
2. /etc/passwd and /etc/group: the account databases
/etc/passwd is a world-readable table of accounts. Each line is colon-separated: username, password placeholder (usually x), UID, primary GID, comment (GECOS), home directory, and shell. The x does not mean the password is public — hashes live in /etc/shadow, which only root should read. A login shell of /usr/sbin/nologin or /bin/false means "this is not a human login," which is what you want for daemons. /etc/group lists group name, placeholder, GID, and optional member usernames. A user has one primary group (the GID field in passwd) and can be listed in extra groups. Teams use extra groups so several people can write a shared project directory without making that directory world-writable. That is least privilege at the filesystem: share with a group, not with the entire planet.
3. Why services run as dedicated users
A web server should not run as root, and it should not run as your personal login either. If nginx is compromised while running as UID 0, the attacker inherits the whole machine. If it runs as www-data, the blast radius is the files that user can read and write — often only web content and logs. Dedicated service users are Principle of Least Privilege applied to processes. mysql, postfix, and sshd workers each get their own UID so a bug in one daemon does not automatically own another daemon's data. When you audit a box, id and /etc/passwd tell you whether "the website" is a locked-down identity or an accidental superuser.
4. Wrong vs right: the web server identity
Worked failure mode — running a network service as the wrong user. Conceptual only; do not reconfigure production daemons without permission.
Wrong
The site "would not start," so someone launched the web server as root and left it that way. A single remote code bug now writes SSH keys, reads /etc/shadow, and plants a cron job. Username on the process is root; UID is 0.
Right
The service runs as a dedicated user (www-data, nginx, or similar) with a nologin shell, membership only in the groups it needs, and no sudo. A compromise is still serious — but it is not instant god mode. You can see that identity with ps, id, and /etc/passwd.
5. Practical: map your identity on your own VM
Run these on your own Linux VM, WSL, or a machine you administer. You are reading account files, not creating users or editing shadow. Look up your UID, confirm it matches /etc/passwd, and find one service account that is not meant to log in.
whoami, id, passwd, group (your VM / WSL only)
# Who am I in this shell?
whoami
id
id -u # numeric UID
id -g # primary GID
id -Gn # group names
# Your account line in the user database (names + UID/GID + shell)
getent passwd "$USER"
grep "^${USER}:" /etc/passwd
# Colon fields: name:x:UID:GID:comment:home:shell
# The 'x' is a placeholder — password hashes are NOT here.
# Groups you belong to
groups
getent group "$(id -gn)"
head -n 15 /etc/group
# Dedicated service users (look, do not edit)
grep -E '^(www-data|nginx|mysql|nobody):' /etc/passwd || true
# DO NOT: usermod, userdel, vipw, or edit /etc/passwd /etc/shadow
# DO NOT: chmod or chown system account files
# Hashes live in /etc/shadow — root-only; do not copy them anywhere.Mission: prove your UID and spot a service user
On your own VM or WSL, run whoami and id. Find your username in /etc/passwd and write down the UID and GID. Then find one non-human account (nologin, false, or a known daemon like www-data/nobody) and write one sentence: "This UID exists so a service does not run as root." Do not add, delete, or modify users.
Stuck? Ask Cyberlium AI Mentor
If /etc/passwd fields still look like noise, ask Cyberlium AI Mentor for a hint — not a dump of every field on a real server. Try: "Hint only: which colon field in /etc/passwd is the UID, and why is the second field usually x?" Reason it out.
You now treat identity as UID and GID, you can read /etc/passwd and /etc/group, and you know why daemons get their own users. Next — File Permissions (chmod, chown) — those numbers become the owner and group on every ls -l line.
Knowledge Check
APPLY: nginx is running as UID 0 after a "quick fix." A remote bug in a plugin executes OS commands. What is the immediate blast radius?
Multiple choice
Knowledge Check
APPLY: You run id and see uid=1000(ana) gid=1000(ana) groups=1000(ana),27(sudo),33(www-data). What did groups buy ana?
Multiple choice
Knowledge Check
APPLY: True or False: Because /etc/passwd is world-readable, it is safe to assume it contains every user's password hash.
True or False