chmod 777

Execute means different things by type. On a file it lets the kernel run it as a program. On a directory it is search permission: entering it (cd) and reaching the files inside by name. Read on a directory only lists names.

• Throwaway directories on a single-user machine or inside a disposable container, where no other account exists to abuse the access.
• For a minute, to prove that an error really is a permissions problem. Then revert to the narrowest mode that works.

• Web roots and upload directories. Any process on the server, including a compromised script from another site on shared hosting, can drop or rewrite your files. The WordPress hardening guide says no directory should ever be 777, not even uploads.
• Shared directories without the sticky bit: every user can delete or rename everyone else's files. Use 1777 (the /tmp mode) or a shared group with 2775.
• Anything under ~/.ssh. ssh ignores private keys that others can access, and sshd with StrictModes (the default) refuses logins when your home, ~/.ssh or authorized_keys is writable by others.

When a web app cannot write to a directory, 777 appears to fix it because it grants write to the others class, which includes whatever account the web server or PHP-FPM runs as (www-data on Debian and Ubuntu, nginx or apache on Fedora and RHEL). It also grants the same write to every other account on the machine.

Give the access to that one account instead: make it the owner, or put it and your deploy user in a shared group and use 775 for directories and 664 for files.

ps -o user= -C nginx,php-fpm,apache2,httpd | sort -u   # who the server runs as
sudo chown -R www-data:www-data /var/www/site/uploads
sudo chmod 755 /var/www/site/uploads

Do not run chmod -R 777. It makes every file in the tree writable and executable by every account. If it already happened, restore a sane baseline with the two find commands below, then add execute back only to the scripts that need it.

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

Git stores only one permission fact per file: 100755 if the owner execute bit is set, 100644 otherwise. A file with this mode is committed as 100755; the group and others bits never reach the repository. On Windows, or where core.fileMode is false, set the bit with git update-index --chmod=+x.

Is chmod 777 safe?

Only where no untrusted account or process can reach the path. On a multi-user system or a web server it lets any account modify or replace the files, so a compromise of any other service becomes a compromise of yours.

What does chmod 777 do to a directory?

Anyone can list it, enter it, and create, delete or rename any file in it, including other users' files, because deleting a file depends on the directory's write bit, not the file's. Adding the sticky bit (chmod 1777) limits deletion to each file's owner.

How do I undo chmod -R 777?

Reset directories and files separately: find . -type d -exec chmod 755 {} + and find . -type f -exec chmod 644 {} +. Then restore execute on the few scripts that need it with chmod +x.

Is chmod 777 the same as chmod a+rwx?

The nine permission bits end up identical. The difference is that the numeric 777 also clears setuid, setgid and sticky on regular files, while a+rwx leaves those special bits as they were.