The “chmod 777” trap: How and why to avoid it
It can be a frustrating experience trying to get your web application to work. When the world seems to be working against you, and you get “permission denied” at every turn, it can be very tempting to break out the “chmod 777” — and give everyone on your server permission to write to your files.
In case you’re not familiar with chmod, it’s a tool to specify access control on your files. The “7” refers to full read, write and execution privileges. The three sevens means that it applies to yourself, to other people in your group, and to everyone else on the server.
While this approach does solve your immediate problem, it isn’t without its own drawbacks. They’re subtle drawbacks; you don’t notice them straight away, but given the right circumstances, they can make your life far more difficult in the long run.
It is true that a good backup regimen will assist you in disaster recovery when you become a victim of the “chmod 777” trap. But while your data is being recovered from backups, your website may be down, costing you valuable income. So why put yourself in that position to begin with?
Why “chmod 777” is a bad idea
Scenario 1: Suppose you are on a shared hosting server, with a hundred other users you don’t know or trust. Imagine you have a user account called “picard”. You upload your website, which contains a PHP form that your users can upload files with. When you try to upload a file using the form, you find that PHP is unable to write to your uploads directory!
Without realising that this problem could be solved with a bit more cleverness in the way PHP is run, you decide the best way to ensure that PHP can write to your uploads directory is to give everyone that permission, because traditional access controls don’t give you a finer degree of control. So you “chmod 777” the uploads directory, and to your great joy and amazement your upload form works!
Now imagine a hostile party creates a hosting account on that same server; we’ll call it “borg”. “borg” logs in with SSH and uses the “find” command to look for world-writable directories in
/home. Since “borg” is able to write to that directory, bypassing your upload form’s validation mechanism, the account can add PHP scripts to that directory, essentially enabling the attacker to add new pages to your website.
This is a small example for demonstration purposes; it could be much worse if the
public_html directory itself were world-writable, as then the “borg” would be able to replace your website’s homepage.
Scenario 2: Now we’ll assume that you’ve decided to upgrade to a VPS, and have moved your hosting account there. Still unaware of the better options for running PHP, you decide to play it “safe” and chmod all of your directories 777, so you’ll never have to worry about permissions issues again.
Should be safe enough. After all, it’s your VPS, right? There are no other users.
That may be so, but PHP and the web server aren’t the only pieces of software that run on any given server. You will typically have a local mail relay, often an NTP server, NRPE if you’re monitoring your server with Nagios, and any number of other daemons.
These daemons, just like all software, are not infallible. Bugs come up from time to time, sometimes serious ones. You don’t want to lull yourself into a false sense of security, only to have an exploit in your mail server used to gain access to a shell, with all of your website’s files writable by the user the mail server runs as.
Sounds far-fetched? It’s true that it’s not the kind of thing that happens every day, but these things do happen. Why leave yourself vulnerable?
How Anchor can help you
I’ve spent this blog post so far preaching about the evils of world-writable files, but this post wouldn’t be complete without some suggestions for alternative solutions.
By far the best solution, if it suits your use case, is to run your web application as the same user as your files are owned by. I’ve already mentioned that we do this for all our shared hosting accounts (and not just for PHP, but for all kinds of CGI and FastCGI scripts too). If you buy your shared hosting from Anchor, you won’t have need for “chmod 777” at all.
There are some situations, however, in which one user needs to be able to write to files owned by another user. There are two solutions to this problem, and which one is correct depends on your specific use case:
- You can use conventional UNIX permissions, placing both users in the same group and making the common files group-writable. This is typically useful for simple setups, where a group of users should all be able to write to some set of files.
- You can use extended filesystem ACLs to give specific privileges to specific users and/or groups. This is a much more powerful and flexible option, but its added complexity makes it best suited to complex setups with many users, each of whom requires access to specific files.
Both of these solutions are used extensively at Anchor. Which one we’ll use depends on the customer’s requirements.
If you’re an Anchor customer and you find yourself with an urge to “chmod 777” your website, think twice. Pick up the phone and give us a call, or send us an email if you have complex requirements that are best laid out in writing, and we’ll provide advice on the best solution for your problem.