When developing a page on a localhost, I sometimes get a "Permission denied" error which I can solve by running chmod -R 777 /var/www. However, people are telling me that this is a bad idea for security reasons.
Why shouldn't /var/www have a chmod of 777?
777 is a bad permission in general and I'll show you why.
Despite how it may look in a Casino or Las Vegas, 777 doesn't mean jackpot for you. Rather, jackpot for anyone who wishes to modify your files. 777 (and its ugly cousin 666) allow Read and Write permissions (and in the case of 777, Execute) to other. You can learn more about how file permissions work, but in short there are three groups of permissions: owner, group, and other. By setting the permission to 6 or 7 (
rw-orrwx) for other you give any user the ability to edit and manipulate those files and folders. Typically, as you can imagine, this is bad for security.Here's my example:
So far I have created a folder and made a file with "bad" permissions (777 and 666). Now I'll switch into another user and try to manipulate those files.
As this "malicious" user I was able to place files into the directory and inject text into already existent files. Whereas below, in a directory with 755 and files with 644, I am able to see inside files and directories but I can not edit the files nor create new ones:
For Apache permissions, you're going to want to stick to 0755 and 0644 (AKA
umask 022) for folders and files respectively. This allows you, as the owner of the files, to edit and manipulate them while giving Apache the bare minimum levels of access needed to operate.Essentially, having permissions of 777 are not going to get you hacked on their own, but if someone gets a toehold in anywhere at all, it can be used to escalate permissions and gain complete control over your computer. The worst part is that your permissions are using "7" - that means read, write, and execute permissions.
Let's say a hacker wants to take over your computer. He might connect to your computer using a web browser, connecting to http://yourcomputer.example.com:80/ . If you have any pages available that let him upload images, he can rename an executable to end with ".jpg" and upload it to your server. Now he browses to that file in his web browser and runs it, because linux doesn't care about the extension, it only sees that it's an executable file. That may not get him much, but because it ran at all, he knows it ran as the apache user. He then uploads a modified version that will edit apache's config files, granting him even more access - let's say so that apache will output the contents of /etc/passwd. He can then use that information to see what users exist on the system. He can then connect using ssh and try common passwords to log in as those users - if that doesn't work he'll step up to using a full brute-force attack. If he gets in as a user with sudo access, then the entire system is his.
Now, you may say that's not likely, or that it's not how a real hacker would work. That is true, but the point is that by setting files to be chmod 777, you've opened a security hole that a hacker can use however he sees fit.
If you instead follow the Principle of least privilege, then that hole doesn't occur, and your system is that much harder to hack. Even though it's more difficult to do things properly, you should still make every effort to do so.