File Permissions and Ownership

Every file and directory has an owning user, an owning group, and three sets of read/write/execute permissions - for the owner, the group, and everyone else. Understanding this one model explains almost every "permission denied" error you'll hit.

Reading ls -l output

ls -l /etc/shadow /usr/bin/passwd

-rw-r----- 1 root shadow    1234 Jan  2 10:00 /etc/shadow
-rwsr-xr-x 1 root root     72712 Jan  2 10:00 /usr/bin/passwd

Breaking down the first column, -rw-r-----:

Columns 3 and 4 (root shadow) are the owning user and group. So /etc/shadow is readable and writable by root, readable by anyone in the shadow group, and inaccessible to everyone else - appropriate for a file holding password hashes.

Changing permissions: chmod

Two notations, both common:

Symbolic - add/remove/set specific bits without touching the rest:

chmod u+x script.sh      # add execute for the owner
chmod g-w file.txt       # remove write for the group
chmod o=r file.txt       # set "other" to read-only, exactly

Octal - set all three groups at once, each digit summing read(4)+write(2)+execute(1):

chmod 644 file.txt   # rw-r--r--  (owner: rw, group: r, other: r)
chmod 755 script.sh  # rwxr-xr-x (owner: rwx, group: rx, other: rx)
chmod 600 id_rsa     # rw-------  (owner only - typical for private keys)

600 and 644 are the two permission sets you'll type most often: 600 for anything sensitive only the owner should touch (SSH private keys - see SSH Keys and Authentication), 644 for ordinary files anyone should be able to read but only the owner should edit.

Changing ownership: chown and chgrp

sudo chown alice file.txt          # change owner
sudo chown alice:developers file.txt  # change owner and group together
sudo chgrp developers file.txt     # change group only
sudo chown -R alice:developers /srv/app/  # recursively, for a whole tree

Changing ownership (as opposed to permissions) requires root/sudo in essentially all cases - see sudo and Privilege.

The setuid bit you saw above

That s in /usr/bin/passwd's permissions (-rwsr-xr-x) is the setuid bit: the program runs with its owner's privileges (root) regardless of who executes it. That's how an ordinary user running passwd is able to write to /etc/shadow, which they otherwise can't touch directly. Setuid binaries are a common privilege-escalation target, which is why find / -perm -4000 (listing setuid binaries) is a standard step in basic system hardening - see Hardening Basics.

Directories are special

Read on a directory means "can list its contents"; execute means "can enter it or access files inside by name even without listing them." A directory with r-- but no x will let you see filenames with ls but not cat any file inside, or cd into it - a frequent source of confusing permission errors that looks unrelated to the file you're actually trying to reach.

See Links: Hard vs. Symbolic for how permissions interact with symlinks specifically.