Understanding Linux File Permissions with Chmod
Every file and directory on a Linux or Unix system carries a set of permission bits that define who can read it, write to it, or execute it. These permissions are split across three categories of users: the file owner, the group assigned to the file, and all other users on the system. Managing these permissions correctly is fundamental to both security and functionality — get them wrong and you'll either lock yourself out of your own files or leave sensitive data wide open.
How the Octal System Works
Each category (owner, group, others) has three permission bits: read (r = 4), write (w = 2), and execute (x = 1). You add the values of the bits you want to get a single digit per category. So 7 means all three (4+2+1 = rwx), 6 means read and write (4+2 = rw-), 5 means read and execute (4+1 = r-x), and 4 means read only. The three digits together form the full octal — for example, 755 means rwxr-xr-x.
The Three Permission Entities
The owner is typically the user who created the file. They usually have the most permissive access. The group is a set of users that share a common role — for example, all members of the www-data group on a web server. Others refers to every other user on the system. Linux checks permissions in order: if you're the owner, owner permissions apply; if you're in the group, group permissions apply; otherwise, the others permissions apply.
Common Permission Patterns
Web server file permissions follow widely-accepted patterns. PHP files and HTML should typically be 644 — the web process (usually running as www-data) needs to read them, but no user should be able to write to them in production. Directories should be 755 — the execute bit on directories grants traversal permission, which is required for Apache or Nginx to serve files within. Upload directories, if they exist, require write access and are often 775 or 770 — the write bit granted to the group (which includes the web server user) rather than to everyone.
Special Permission Bits
Beyond the standard 9 bits, Linux supports three special bits encoded as a fourth octal digit. The setuid bit (4000) causes an executable to run with the permissions of the file's owner rather than the invoking user — the classic example is /usr/bin/passwd, which needs root access to update /etc/shadow. The setgid bit (2000) on a directory makes new files within it inherit the directory's group instead of the creator's primary group — very useful for collaborative project folders. The sticky bit (1000) on a directory (like /tmp) prevents users from deleting files they don't own, even if they have write access to the directory.
Reading Symbolic Notation
The ls -l command shows permissions in symbolic form, like -rw-r--r--. The first character indicates type (- for regular file, d for directory, l for symlink). The next nine characters are three groups of three: the owner's rwx, then the group's rwx, then others' rwx. A dash means the bit is not set. This tool translates between symbolic and octal in real time, so you can always check what a cryptic permission string actually means before applying it.
Security Best Practices
Follow the principle of least privilege: grant only the permissions that are actually needed for the application to function. Never use 777 in production — it tells every process on the machine it can do anything with that file. Sensitive files like .env, config.php, or private key files should be 600 (owner read/write only) or 400 (owner read only) to prevent accidental exposure. Run regular permission audits with find to catch files that have drifted from your baseline policy.