File Permission

A file permission is a rule attached to a file or directory that states which users may read it, write to it or execute it. The operating system checks the rule every time a process tries to open, modify, run or list something, so permissions are the basic mechanism that keeps one user's files private from another, protects system programs from accidental or malicious modification, and decides which programs are allowed to start.

The classic Unix model gives every file an owner, a group and three permission bits for each of three classes, and this compact design has survived since the early 1970s. The three bits are read (r), write (w) and execute (x), and the three classes are the owning user, the owning group and everyone else (other). Running ls -l displays them as a string such as -rwxr-xr-- : the first character is the file type, followed by three triplets for user, group and other. The meaning of each bit depends on the object: on a regular file, execute means it may be run as a program, whereas on a directory, read permits listing the names inside, write permits creating, deleting and renaming entries, and execute (sometimes called search) permits passing through the directory to reach anything beneath it. A file can therefore be unreadable yet deletable if its directory allows writing, a counterintuitive result of directories being lists of names.

Octal modes are shorthand for the same bits: read counts as 4, write as 2 and execute as 1, and adding the values for each class gives one digit. The mode 754 means 7 (4+2+1, read, write and execute) for the owner, 5 (4+1, read and execute) for the group and 4 (read only) for others, which is exactly rwxr-xr--. Common values are 644 for ordinary files (owner edits, everyone reads), 755 for programs and directories, and 600 for secrets such as private SSH keys, which the ssh client refuses to use if other users can read them. The chmod command changes modes, either numerically or symbolically (chmod u+x script.sh), chown and chgrp change ownership, and the umask setting removes bits from the defaults for newly created files. Additional special bits exist: setuid and setgid make a program run with its owner's or group's identity, and the sticky bit on a directory such as the temporary-files directory prevents users from deleting each other's files.

chmod 754 deploy.sh
ls -l then shows -rwxr-xr--
One octal digit per class (r=4, w=2, x=1)
Owner: 7 = 4+2+1
rwx: read, write, execute
Group: 5 = 4+0+1
r-x: read and execute
Other: 4 = 4+0+0
r--: read only
Process requests access to the file
kernel compares the process's user and group IDs with the file's owner and group
Result
Matching class allows the action
operation proceeds
Matching class denies it
permission denied error returned

Access control lists extend the three-class scheme when it is too coarse, by attaching any number of per-user and per-group entries to a single object. Under plain mode bits, granting one extra colleague write access forces the creation of a new group, whereas an ACL can simply add a named user entry. POSIX.1e drafts defined such lists for Unix (the draft was never finalized, but Linux and others implement it, managed with setfacl and getfacl), and Windows NTFS has used ACLs from the start, with entries that can allow or deny specific rights such as read, modify or take ownership, and that are inherited from parent folders. Cloud object stores and databases apply the same idea under names such as bucket policies and grants. The matching trade-off is that ACLs are more flexible but harder to audit, since the effective access for a file may come from several entries and inheritance rules.

Permissions matter everywhere in practice, and the most common pitfall is solving a permission denied error by loosening everything. Running chmod 777, which gives every user full control, makes the error disappear but also lets any account or compromised service modify the file, which is why web servers, deployment scripts and containers are expected to follow the principle of least privilege and grant only the access a process actually needs. Another misconception is that permissions encrypt anything: they are enforced by the operating system, so a user with administrator rights, or anyone who boots the disk elsewhere, can bypass them, and confidentiality against such access requires encryption. Permissions also explain routine failures in data science and machine learning work, such as a notebook unable to write to a mounted volume or a script that will not run because it lacks the execute bit.

Read a file permission as the operating system's per-object answer to the question of who may do what: a short pattern of read, write and execute bits for owner, group and everyone else, optionally refined by access control lists, checked on every access and best set to the narrowest value that still lets the work get done.

Take file permission further

Ask the copilot about this term, or have our engineers assess it against your process.