Linux Users, Passwords and Permissions: /etc/passwd, /etc/shadow and chmod Explained

TrainingOctober 9, 2026

TrainingLinux · blue teamLevel BeginnerWritten lesson · try it on any Linux machineExam Linux+ · Security+ V8

On Linux, password hashes live in /etc/shadow, which only root can read. /etc/passwd lists the accounts and anyone can read it, which is exactly why the hashes moved out of it. This page explains those two files, how to read a permission string like -rw-r-----, and what to check so a copy of your hashes never ends up readable.

Steven once ran chmod 777 to “fix” a permissions error. It fixed it the way removing the front door fixes a sticky lock. — Nyx

Every command here is read-only or works on a test file you create, so it’s safe on your own machine or a lab VM. Output below is from Ubuntu 24.04; other distributions differ in small ways, which we point out. Tell us if yours doesn’t match.

Three files, three jobs

/etc/passwd — who exists. One line per account: name, a placeholder x where the password used to be, user ID, group ID, a description, home folder and login shell. Readable by everyone, because lots of programs need to turn a user ID into a name.
/etc/shadow — the secrets. The password hash plus password-age rules. Readable only by root (and on Debian and Ubuntu, the shadow group).
/etc/group — which groups exist and who is in them.

$ ls -l /etc/passwd /etc/shadow /etc/group
$ getent passwd "$USER"

-rw-r--r-- 1 root root    959 Oct  2 11:43 /etc/group
-rw-r--r-- 1 root root   3333 Oct  2 11:43 /etc/passwd
-rw-r----- 1 root shadow 1379 Oct  2 11:43 /etc/shadow

Notice the difference: rw-r--r-- (everyone can read) for passwd, rw-r----- (owner and group only) for shadow. On Red Hat, Fedora and similar systems, /etc/shadow has no permissions at all (----------) and only root gets in.

Reading a shadow line

A shadow line has nine fields separated by colons. The second one is the hash, which itself starts with an ID that says which algorithm made it:

$y$ — yescrypt. The default on Debian 11+, Ubuntu 22.04+ and Fedora 35+. Deliberately slow and memory-hungry, which makes cracking expensive.
$6$ — SHA-512 crypt. The common default before yescrypt. Still acceptable.
$5$ — SHA-256 crypt.
$1$ — MD5 crypt. Old and fast to crack. If you find one, reset that password.
! or * in place of a hash — the account can’t log in with a password (locked, or a system account).

To see which algorithm your own account uses without printing the hash itself:

$ sudo awk -F: -v u="$USER" '$1==u {split($2,a,"$"); print "algorithm id:", a[2]}' /etc/shadow

Fun one: on our Ubuntu test box, /etc/login.defs says ENCRYPT_METHOD SHA512, but a password set through the normal tools came out as $y$, because the login system (PAM) has its own setting. Believe the shadow file, not the config file. — Nyx

The other fields are dates and rules, counted in days since 1 January 1970: when the password was last changed, the minimum and maximum days between changes, how many days of warning to give, and when the account expires. sudo chage -l <user> shows them in plain English.

Permissions in one look

A permission string has ten characters. The first is the type (- file, d directory, l link). The next nine are three groups of read, write and execute: for the owner, the group, and everyone else.

Each group is also a number: r = 4, w = 2, x = 1, added together. So -rw-r----- is 6 (4+2) for the owner, 4 for the group, 0 for everyone else: 640. On a directory, r lets you list it and x lets you go into it.

$ touch demo.txt; ls -l demo.txt
$ chmod 640 demo.txt; ls -l demo.txt
$ chmod u+x,o-r demo.txt; stat -c '%A %a' demo.txt

-rw-r--r-- 1 you you 0 Oct  9 16:27 demo.txt
-rw-r----- 1 you you 0 Oct  9 16:27 demo.txt
-rwxr----- 740

New files start at 644 because of the default umask of 022, which removes write permission for the group and everyone else. chmod changes permissions, chown changes the owner, and chgrp changes the group.

The three special bits

setuid (an s where the owner’s x would be) — the program runs as its owner, not as you. /usr/bin/passwd is -rwsr-xr-x because changing your password means writing to /etc/shadow, which you can’t do yourself.
setgid on a directory — new files inside inherit the directory’s group. Useful for shared team folders.
sticky bit (a t at the end, as on /tmp: drwxrwxrwt) — everyone can create files, but only the owner can delete theirs.

What attackers look for, and the check that stops it

The attacker’s view. Hashes don’t need to be read on the machine. If an attacker gets a readable copy, such as a backup of /etc/shadow, a disk image, or a config-management export, they can try to crack it offline at their own pace. Old $1$ hashes and short passwords fall first.

The defender’s move. Make sure no copy of the shadow file is readable by everyone, and keep an inventory of setuid programs so a new one stands out.

$ ls -l /etc/shadow*
$ sudo find / -xdev -type f \( -name shadow -o -name 'shadow-' -o -name 'shadow~' -o -name 'shadow*.bak' -o -name 'shadow.old' \) -perm -o=r 2>/dev/null
$ sudo find / -xdev -perm -4000 -type f 2>/dev/null > suid-baseline.txt; wc -l suid-baseline.txt

The first command should show /etc/shadow- (an automatic backup) with the same permissions as the original. The second looks for readable copies under the usual backup names and should print nothing. (We planted a readable shadow.bak on our test box to check that it gets caught: it does.) Save the third file and compare it after updates: a setuid program that appears out of nowhere is worth asking about. On our test box the list had 12 entries, all part of the standard install.

Interview quick-fire

Q: Where are local password hashes stored on Linux? A: /etc/shadow, readable only by root (plus the shadow group on Debian-based systems).
Q: Why isn’t the hash in /etc/passwd any more? A: Everyone can read /etc/passwd, so anyone could copy the hashes and crack them offline.
Q: What does 640 mean? A: Owner read and write, group read, everyone else nothing.
Q: Why is /usr/bin/passwd setuid? A: It has to write to /etc/shadow on your behalf, so it runs as root.
Q: What does $y$ at the start of a hash tell you? A: It was made with yescrypt, the current default on most major distributions.

Go deeper

Strong passwords and passphrases — why length beats complexity against offline cracking
hashcat — the cracking tool defenders test their own policies with
Linux privilege escalation cheat sheet — how misconfigured permissions and setuid files get abused, so you know what to audit
Lab 14: Make sense of giant logs — more terminal practice, on a realistic outage

Original explainer. Commands and output checked on Ubuntu 24.04 on 9 October 2026. Red Hat-family permissions and default hash algorithms are as documented by those distributions; we didn’t test them on a live system. If something doesn’t match your machine, tell us and we’ll fix the page.