Linux File Permissions And Chmod Patterns

This deck walks you through Linux file permissions from the ground up, starting with the meaning of symbolic patterns like rwxr-xr-- and moving into the numeric equivalents such as 644, 755, 600, and 700. As you progress, you'll practice translating between the two notations, explore special bits like setuid, setgid, and the sticky bit, and learn why permissions matter in real situations such as securing an ~/.ssh directory. You'll also cover recursive changes, ownership commands, reading permissions with ls, and how umask shapes the defaults for newly created files and folders.

It's a great fit if you're a beginner learning the Linux command line, a sysadmin refreshing the fundamentals, or a developer who has been getting away with copy-pasted chmod commands and now wants to understand what's actually happening. The mix of symbolic and numeric formats means you'll build fluency in both, which is essential for reading scripts, troubleshooting permission errors, and passing common certification topics.

To get the most out of these cards, try to visualize a file's mode bits as three independent sets (owner, group, other) rather than memorizing patterns as single numbers. When studying, pause to actually open a terminal and run ls -l, chmod, and umask on a scratch directory so the conversions move from abstract rules to muscle memory. Spacing your review over several short sessions tends to work better than cramming, especially since the special bits (setuid, setgid, sticky) benefit from repeated exposure before they fully stick.

Every file and directory on a Linux system carries a permission mode made of three permission classes — owner, group, and other — each expressed as a string of read (r), write (w), and execute (x) bits. The familiar rwxr-xr--, for example, breaks down as read, write, and execute for the owner (value 7), read and execute for the group (value 5), and read only for everyone else (value 4). Because each class is independent, the same string can also be written as the octal number 754. The same conversion works in reverse: 644 maps to rw-r--r--, 755 to rwxr-xr-x, 600 to rw-------, and 700 to rwx------. The 700 and 600 patterns are commonly applied to private SSH material because SSH itself refuses to use a key inside a directory or with permissions that any other user can reach. To retrieve a numeric mode in a script-friendly form, stat -c '%a %U %G %n' file prints the octal mode alongside owner, group, and filename.

The first character of an ls -l line conveys the file type rather than a permission: d marks a directory, l a symbolic link, - a regular file, c or b a character or block device, and s or p a socket or named pipe. A file whose owner field reads as user 0 is owned by root, which is why many privileged system utilities are installed as root-owned setuid binaries. Symlinks deserve special attention: their permission string is always reported as 777, because permission checks are performed on the target of the link, not on the link itself. This is also why ./script can return "Permission denied" even when the script is plainly visible and readable to the user — running a program requires the execute bit, which is set with chmod +x script, or with the more explicit chmod u+x script to add it only for the owner.

When new files and directories are created, their initial mode is determined by combining a base value with the process's umask using a bitwise AND of the complement. Files start with a base of 666 (no execute bit) and directories with 777. A typical Ubuntu desktop runs with a umask of 022, yielding 644 for new files and 755 for new directories. Tightening the umask to 077 produces 600 and 700, ensuring that nothing is visible to other users. Loosening it to 002 gives 664 for files, which is useful when working inside a shared group where collaborators are expected to edit each other's files.

The standard rwx bits cover most situations, but Linux also defines three additional flags that change the meaning of executable files and shared directories. The setuid bit, set with chmod u+s or as the leading 4 in a four-digit octal mode such as 4755, causes a program to run with the file owner's identity rather than the caller's — /usr/bin/passwd is the canonical example, written numerically so that ordinary users can change their own password while the program runs as root. Used carelessly, setuid is dangerous; modern kernels offer capabilities as a more focused alternative that grants only specific privileges instead of full root.

The matching setgid bit on a directory (chmod g+s dir) makes new files and subdirectories created inside it inherit the directory's group, which is invaluable for collaborative trees like a shared/ workspace. A third flag, the sticky bit (chmod o+t, or leading 1 in four-digit octal, as in 1777) is what gives /tmp the mode rendered rwxrwxrwt: every user may create files there, but only the file's owner (and root) may delete or rename them, even though the directory itself is world-writable. This single mechanism keeps one user's temporary files safe from another user on a shared host.

Short symbolic forms are often quicker than four-digit octal. The shorthand chmod u=rwx,g=,o= file sets the owner to full rwx and clears every other class, which is equivalent to chmod 700 file. When these special bits interact with mount options, the kernel still wins. Filesystems mounted with noexec prevent any program inside from being executed, even when the execute bit is set — a common hardening for /tmp to stop malware that tries to run from there. nosuid similarly ignores any setuid bits on the mount, which is why the same idea is sometimes applied to user-writable areas. In these cases it is the mount, not chmod itself, that governs effective behavior.

Permissions only tell half the story; the other half is who owns a file. Ownership is changed with chown user:group path, optionally with -R to descend into subtrees, and with chgrp -R group path when only the group needs adjustment. By design, only root can transfer a file to a new owner — a regular user cannot give away a file they own, which prevents users from handing troublesome material to another account. Inside recursive operations, chown -R changes the ownership of symlinks themselves rather than their targets; the -h flag is added when an operation should affect the symlink directly rather than what it points to.

Standard patterns emerge quickly when restoring a directory tree to a clean state. The canonical recipe sets 755 on every directory and 644 on every file by walking the tree twice with find, once per type, and invoking chmod on each match: find dir -type d -exec chmod 755 {} + followed by find dir -type f -exec chmod 644 {} +. The same find … -exec chmod … {} + idiom is used when resetting ownership after a deploy or restore. When copying permissions from a reference file, chmod --reference=src dst saves the trouble of computing octal values by hand. Typical ownership patterns for an Apache web root set directories to 755 owned by the deployer with group www-data, files to 644, and writable upload directories to 775 or 770 owned by www-data itself.

Creating a file with a known mode from the start is sometimes preferable to editing it after the fact. The install command is built for this: install -m 600 src dst copies a file while applying a chosen mode, owner, and group in one step, sparing the user from a separate chmod. Personal scripts that live in ~/.local/bin generally need 755 to be runnable as commands, while a private utility is sometimes locked down to 700 — the rule is simply that the execute bit must be set for whichever user is meant to invoke the file. Together, chown, chmod, and install form the daily toolkit of permission administration on Linux.

A handful of well-known system files have modes that look surprising on first contact, but each has a clear reason. SSH is the strictest case: the ~/.ssh directory must be 700 and the private key (typically id_ed25519) must be 600, otherwise the SSH client refuses to use the key — a deliberate security check. The matching public key is 644, and authorized_keys is normally 600 as well. These defaults protect the cryptographic material from any user who happens to share the machine.

Password storage follows the same idea. /etc/passwd is world-readable (644) because countless utilities need to map numeric UIDs to usernames; only the password hashes live elsewhere, in /etc/shadow at 640 owned by root:shadow. This split lets the system identify users while keeping the actual secrets locked away. The general rule is that things everyone needs to read stay readable, while secrets get a restrictive mode.

Beyond traditional Unix permissions, two extended attributes provide stronger protection. chattr +i file marks a file as immutable, so even root cannot modify or delete it until chattr -i reverses the bit; root can normally do anything filesystem-wise, but immutable files remain out of reach. chattr +a logfile sets the append-only flag, allowing data to be added to the end of a file but preventing truncation or rewriting — ideal for tamper-evident log files. Both flags can be inspected with lsattr file. When a permission error says "Operation not permitted" on a file the user clearly owns, the immutable attribute, a read-only mount, or a MAC policy such as SELinux or AppArmor is usually the culprit rather than the Unix mode itself.

The classic user/group/other model is sufficient for many systems, but it cannot grant access to a fourth specific user without making the file world-readable. POSIX ACLs solve this. setfacl -m u:alice:r file grants Alice read access on a file, and multiple entries can be combined in a single invocation: setfacl -m u:alice:r,u:bob:rw,g:devops:rwx file. The matching query is getfacl file, which prints the full ACL alongside the traditional mode. ACLs may also define a default ACL on a directory — setfacl -d -m u:alice:rx dir — which automatically propagates to new files and subdirectories created inside. A web service such as www-data can therefore read a file owned by another user either when the file is world-readable, when www-data appears in the owning group, or when an ACL grants the access.

ACL administration follows the same backup discipline as any other configuration: getfacl -R / > acls.bak records every ACL under a tree, and setfacl --restore=acls.bak replays them. To strip all ACLs and return a file to the simple Unix model, setfacl -b file suffices. Some filesystems, notably FAT32, only support the eight bits of legacy DOS attributes, so POSIX ACLs cannot be stored natively there; mount options may simulate them, but this is always a shim rather than true ACL storage. Native Linux filesystems like btrfs and XFS do support POSIX ACLs alongside extended attributes, and XFS additionally exposes DMAPI metadata.

An entirely different way to extend privilege is through POSIX capabilities. Instead of giving an entire binary setuid root, the binary can be granted just the specific capability it needs. A common example is binding to a low port: setcap cap_net_bind_service=+ep /path/binary allows the program to listen on port 80 without the wider powers of root. The granted capabilities are queried with getcap binary. Together with SELinux and AppArmor MAC policies, capabilities form the modern alternatives to setuid and ACLs for fine-grained privilege control.

When permissions behave unexpectedly, several layered tools help diagnose the cause. To find setuid binaries — both for auditing and for spotting potential privilege-escalation paths — find / -perm -4000 -type f 2>/dev/null lists them across the filesystem, suppressing permission errors. The parallel audit for world-writable files is find / -type f -perm -o+w -not -path '/proc/*' -not -path '/sys/*'. When a single chmod call fails and the error looks opaque, strace -e trace=chmod chmod 755 file shows the kernel syscall and the precise errno, exposing read-only mounts, immutable flags, or LSM denials. In practice chmod itself is rarely blocked from setting a bit on a file you own; the failure almost always lives in a flag or mount option rather than in chmod's logic.

Read-only file behavior can also be confirmed at the mount level: mount | grep ' ro,' or inspecting /proc/mounts reveals which filesystems are mounted read-only. Bind mounts allow a particular directory to be remounted read-only through mount --bind /src /dst followed by mount -o remount,ro /dst, useful for handing a read-only view of data to a service. To make an entire directory tree read-only in user space, chmod -R a-w path strips the write bit from every class on every entry. The /etc/sudoers file expects mode 440 owned by root:root, and edits should always go through visudo so the syntax is validated before saving — a small habit that prevents locking oneself out of root.

Beyond traditional Unix permissions, mandatory access control systems add a second decision point. SELinux contexts can be reset with restorecon -Rv path, which re-applies the labels defined by policy after copying files or restoring backups. AppArmor profiles live in /etc/apparmor.d/ and can be inspected with aa-status. Alongside these policy frameworks, the kernel tracks the difference between the real user ID (RUID, who invoked the program) and the effective user ID (EUID, the identity used for permission checks, often changed by setuid); the running identity is exposed by whoami or id -un, with UID and GID available through id -u and id -g. Together, ACLs, capabilities, and LSM policies extend Linux permissions far beyond the rwx triple into a layered, defense-in-depth model.