Unix File Permissions Explained: Why chmod 777 Is Never the Answer

Every developer has done it. Your deployment script fails with "Permission denied." You are tired. It is 11 PM. You type chmod 777 /var/www/html and everything works. You go to bed. Three months later, your server is compromised because every user on the system could write to your web root, and an uploaded PHP file gave an attacker a shell. I have seen this exact sequence play out on production systems more than once. The fix is not complicated -- it is understanding what those three digits actually mean and picking the right ones. The permission model Every file and directory on a Unix system has three sets of permissions, assigned to three classes of users: Owner (u): the user who owns the file Group (g): users who belong to the file's group Others (o): everyone else Each class gets three permission bits: Read (r = 4): view file contents, or list directory contents Write (w = 2): modify the file, or create/delete files in a directory Execute (x = 1): run the file as a program, or ent