Linux Permissions

What Are Linux Permissions?

Every file and directory carries three permission sets — for the owner, the group, and others — each with read (r), write (w), and execute (x) bits.

ls -l file.txt
# -rwxr-xr-- 1 deploy developers 1024 Jan 20 10:00 file.txt
#  |||||||||
#  owner: rwx   group: r-x   others: r--

flowchart LR F[file.txt] --> O["Owner: rwx"] F --> G["Group: r-x"] F --> OT["Others: r--"]

What r/w/x Mean — Files vs Directories

Bit	On a File	On a Directory
`r`	Read file contents	List directory contents (`ls`)
`w`	Modify file contents	Create/delete/rename entries inside
`x`	Execute the file as a program/script	`cd` into it / traverse it

A very common trap: you can delete a read-only file if you have write permission on its parent directory — permission to delete is a directory-level operation, not a file-level one.

chmod: Numeric vs Symbolic

# Numeric (octal): r=4, w=2, x=1 — sum per group
chmod 754 file.txt     # owner rwx(7), group r-x(5), others r--(4)
chmod 644 file.txt     # standard for regular files: owner rw-, group/others r--
chmod 755 script.sh    # standard for executables/directories

# Symbolic
chmod u+x script.sh    # add execute for owner
chmod g-w file.txt     # remove write for group
chmod o=r file.txt     # set others to read-only exactly
chmod -R 755 dir/      # recursive

Ownership: chown / chgrp

sudo chown deploy file.txt          # change owner
sudo chown deploy:developers file.txt   # change owner and group together
sudo chgrp developers file.txt      # change group only
sudo chown -R www-data:www-data /var/www/html

Special Permission Bits

Bit	Numeric	Effect
setuid	`chmod u+s` (4000)	Executable runs with the file owner’s privileges, not the caller’s (e.g., `/usr/bin/passwd` runs as root so any user can update `/etc/shadow`)
setgid	`chmod g+s` (2000)	On a directory, new files inherit the directory’s group automatically
sticky bit	`chmod +t` (1000)	On a directory, only the file’s owner (or root) can delete/rename it — used on `/tmp`

ls -ld /tmp
# drwxrwxrwt   <- the trailing 't' is the sticky bit

chmod +t /shared_uploads/     # prevent users from deleting each other's files
chmod g+s /team_dir/          # new files automatically belong to the team's group

umask: The Default Permission Mask

umask subtracts bits from the default (666 for files, 777 for directories) when a file is created.

umask            # e.g., 0022
touch newfile    # results in 644 (666 - 022)
mkdir newdir     # results in 755 (777 - 022)

ACLs: Beyond owner/group/other

For finer-grained control than the three standard classes allow:

setfacl -m u:alice:rw file.txt     # grant alice rw, without changing owner/group
getfacl file.txt                   # view ACL entries

Production Considerations

chmod -R 777 “to fix a permission error” is a red flag in review — it usually masks a real ownership/group misconfiguration and opens a security hole.
setuid binaries are a classic privilege-escalation vector — audit them regularly: find / -perm -4000 -type f 2>/dev/null.
In containers, UID/GID mismatches between the host and container user are a frequent source of “permission denied” on mounted volumes — align them explicitly rather than running everything as root.

Quick Interview Answer

“Linux permissions are three rwx triplets for owner, group, and others. Numeric chmod sums r=4/w=2/x=1 per class; symbolic chmod uses u/g/o with +/-/=. Special bits matter too: setuid runs a binary as its owner (like passwd), setgid makes new files in a directory inherit its group, and the sticky bit (used on /tmp) stops users deleting files they don’t own even with directory write access.”

Common Mistakes

Using chmod 777 as a quick fix instead of diagnosing the real ownership/group issue.
Forgetting that deleting a file depends on the parent directory’s write permission, not the file’s own permissions.
Not knowing the difference between setuid and setgid in an interview.