Chmod calculate.

Two notations, one bit pattern.

Unix file permissions are nine bits — three for the owner, three for the group, three for everyone else. Each triplet is read (r), write (w), execute (x). Octal numbering compresses each triplet into a single digit using powers of two: read = 4, write = 2, execute = 1. Sum the bits and you get a digit from 0 to 7. Three triplets give a three-digit number — 755, 644, 600, the values UNIX administrators have memorised since the 1970s. Symbolic notation expresses the same nine bits as a nine-character string: rwxr-xr-x for 755, rw-r--r-- for 644.

Both notations describe the same underlying mode word, a 16-bit value where the lower 9 bits hold the rwx triplets and bits 9–11 hold setuid, setgid, and sticky. stat() returns the mode in st_mode; chmod(2) takes it as a parameter. The shell command chmod accepts both notations: chmod 755 file sets the absolute mode; chmod u+x file adds execute for owner without touching other bits.

Why directories need x.

The execute bit on a directory has nothing to do with executing programs. It controls whether the directory's contents can be traversed — whether a process can cd into the directory, or open a file by full path inside it. Without execute, the directory cannot be entered even if read permission allows listing its names.

This matters because the three permissions interact non-obviously on directories. Read alone lists names but cannot stat them (so ls works but ls -l shows ? for sizes and dates). Execute alone allows access to known paths inside the directory but not directory listing. Read + execute is the normal "look inside" mode. Write + execute is required to create or delete files. The standard 755 on directories grants traversal to everyone and write only to the owner.

The umask interacts with this: most shells default to umask 022, which clears the world-write bit on newly created files. Set umask 077 for a private user (owner-only access by default) or umask 002 in shared-group environments where group-write is normal.

setuid, setgid, sticky.

Three bits sit above the standard nine. setuid (octal 4000) on an executable causes the program to run as the file's owner regardless of who invokes it. This is how passwd can update /etc/shadow when invoked by a normal user, and how sudo bootstraps elevation. It is also a major attack surface — any setuid binary that can be tricked into executing arbitrary code becomes a privilege-escalation primitive.

setgid (octal 2000) on an executable runs it with the file's group; on a directory it makes new files inherit the directory's group instead of the creating user's primary group. This is how shared project directories work: chgrp project /srv/project && chmod 2775 /srv/project means anyone in the project group can write, and any file they create joins the project group automatically.

Sticky bit (octal 1000) on a directory means only the file owner (or root) can delete or rename files inside it, even if other users have write permission on the directory. The canonical use is /tmp on every Unix system: world-writable so anyone can create temp files, sticky so users cannot delete each other's temp files. Without sticky, world-writable directories are a rename-attack waiting to happen.

When nine bits aren't enough.

The classic owner/group/other model has been shipping for fifty years. It is fast (one mode word per inode), simple, and adequate for most filesystem access control. But there are cases where you need more — multiple groups with different permissions on the same file, named-user grants, default permissions for newly created files. POSIX ACLs (Access Control Lists) extend the model: each file can carry a list of named-user and named-group entries with their own rwx triplets.

Most Linux filesystems support ACLs but disable them by default. Mount with acl option, then use getfacl and setfacl to view and modify. ls -l shows a trailing + on files with ACLs. ACLs make permission auditing harder — stat alone no longer tells the full story — but they remove the need for awkward group-juggling.

Beyond POSIX ACLs, modern filesystems offer richer models. NFSv4 ACLs map onto Windows NTFS-style ACLs for cross-platform shares. SELinux and AppArmor add mandatory access control on top of discretionary permissions: even root cannot read a file if the security policy forbids it. Linux capabilities (the cap_* bits) replace setuid for most modern use cases — instead of "run as root," they grant fine-grained privileges like "bind to ports below 1024" or "set system clock."

Five decades of nine bits.

The owner/group/other model dates to UNIX V7 (1979). The nine bits — three for each principal — fit exactly into the lower 9 bits of a 16-bit mode word, with the high bits reserved for setuid, setgid, and the sticky bit (originally meaning "keep this program's text segment in swap"; later repurposed for the world-writable-directory case it serves today). The minimalism was deliberate. Disk space and memory were tight; the model had to fit in two bytes per inode.

The 9-bit model has outlasted dozens of richer alternatives. VMS had four-tier ACLs in the 1980s. Windows NT shipped with full ACLs from launch in 1993. Andrew File System (AFS) has had directory-level ACLs since the late 1980s. None displaced the UNIX rwx model because it had two unbeatable advantages: the kernel could check it in a single load and three bitwise ANDs, and any user could memorise the entire model in five minutes.

Octal notation predates the bit pattern. UNIX shipped with PDP-7 and later PDP-11 CPUs whose word sizes were multiples of three bits, making octal a natural way to express groups of three. By the time x86 took over and base-2 became the dominant view of byte-aligned values, the chmod numbers were already burned into administrator muscle memory. They remain octal in 2026 for the same reason IPv4 still uses dotted decimal — because changing it would break every script ever written.