The FastCGI Caveat: Web Server Secrets, Part 7
Many servers run their PHP and CGI scripts precisely as I describe above. That is, you and your script are two entirely different persons, so far as file ownership is concerned.
But… what if your script pretended to be you? Wouldn’t that simplify things? Of course it would. Never again do you have to worry about those subtleties of file ownership. What’s yours is yours, and what’s the script’s is yours too.
But… how does the script become you? That’s a very tricky thing to do in Unix or Linux. What’s important here, is for you to know when this is happening. Why is it important? Because it makes such a tremendous difference to how you set up your file permissions.
Okay, so you need to know if your scripts become you, or not. How do you find out? That’s easy – you ask your server admin. What’s difficult, is knowing what question to ask. There is no single correct question to ask! Like I said, this is a tricky issue in Unix and Linux, and therefore truly cool.
Ask Your Server Admin
Try asking the question this way: If I upload a file a file for my PHP or CGI script to edit, does the file need to have 644 permission, or 666 permission? Unfortunately, your admin might miss the point of the question. So, at the same time, ask this second question: If my CGI script creates a file, is that file owned by my ftp user id, or is it owned by the Apache server’s user id? If your admin has no idea what you’re asking, consider that a clue.
This bit of trickiness has a number of different names in Unix and Linux; the most common are SuExec and CGIWrapper. For PHP scripts, this is an option of FastCGI. All of these mean that your PHP or CGI script pretends to be you.
Remember that if you change servers – such as upgrading to a dedicated server – the answer to your question will probably change, and that means your file and directory permissions must change too!
Surely I have convinced you that using this trickiness would save a whole lot of hassle? Why do many Unix and Linux server setups not use this trickiness? It’s not a question of convenience, but one of security.
Server Security
It’s time to back up, and think like your server admin. Do you want your server hacked? Of course not! Neither does your admin. Do you want some other idiot on your server bringing the thing to its knees, so that your domains become unavailable? Of course not! Neither does your admin.
Therefore, on a shared server, your admin will do various things to protect you from your colleagues, and to protect your colleagues from you. This is Unix or Linux, and that means you’re all sharing a departmental computer.
There are two basic approaches to PHP and CGI script security, and you already know what those are. The first approach says the script is not you, and the second approach says the script is you. If you understand that, you understand PHP and CGI security!
Not You
The first approach means you need to have your files and directories wide open. For your PHP or CGI script to create a file, that file’s directory must have 777 permission. You can’t get more open than that – there’s nothing wider. To edit a file, the file must have 666 (or 777) permission. Again, that’s as unsecure as it’s possible to be in Unix and Linux.
Why is this a good thing? Because you only need to make certain files and directories vulnerable. You can keep the rest of your files untouchable. Your PHP or CGI script therefore has very clear-cut boundaries. It cannot create new files or edit other files even if it wanted to. It can only touch the places where you have explicitly given it permission.
The popular blogging and Content Management System software WordPress, for example, only requires that the wp-content directory have wide-open permission.
Using this approach, some of your stuff is wide open, but the rest of your stuff is untouchable. This is a standard (and secure) approach. Of course, you could do something really dumb like this:
find . -exec chmod ugo+rw {} \\;
What have you done? You’ve just made all of your files completely vulnerable. Your script can edit them, but so can anyone else who happens to be on your server. On a shared server, this is a problem. On a dedicated server (or virtual dedicated server), this is not a problem – until someone figures out how to hack your script.
Is You
The other approach is for the script to pretend to be you. This is the more common approach for a shared server. Do you see the primary reasons?
I’m sure you see the first reason… if you’re on a shared server, you’re likely to be less experienced. You’d probably rather not be bothered with the complexities of Unix or Linux ownerships and permissions. Your PHP or CGI script pretends to be you, and everything works the way you would expect.
The other reason is more subtle. You’re forced to be a good neighbor. Have you considered messing with your neighbor’s files, either by accident or on purpose? Can you pop into the server via ftp, and mess with the other guy’s files? Of course not – you don’t own them. And now, neither can your PHP or CGI script, because the script is no more (and no less) privileged than you are.
Consider the other situation – that is, when the script does not pretend to be you. It does not pretend to be your neighbor either. If you both run PHP or CGI scripts, you both need to leave certain files and directories wide open. And, therefore, you are vulnerable to each other.
Therefore, rather than leave you vulnerable to your neighbors, your server admin will probably configure the Apache server in such a way that your scripts pretend to be you. Your neighbor’s scripts pretend to be him, and therefore can’t mess with your stuff.
On a dedicated server, you don’t need to worry about malicious neighbors. You’re the only user of the server. Therefore, the first approach makes more sense. The script does not pretend to be you, and therefore you can limit its access to only certain files and directories.
On a shared server, your greater danger is from your neighbors – remembering that your neighbor could be a victim of a hacking expedition. It makes more sense for your scripts to run as if they were you, sidestepping those permissions problems, and keeping you out of your neighbor’s stuff.
Warning
Unix (and therefore Linux) and arrogance go together. Larry Wall, the creater of Perl, calls it hubris, and declares it to be a mandatory trait. A generation ago, the standard answer to any Unix question was “read the man page.” It may take you several days to figure out which man page to go read; that fact was both assumed and expected. No self respecting Unix guru will waste his time with someone incapable of figuring out which man page to read; and all Unix gurus are self respecting.
Don’t be put off by the arrogance and condescension of this article. I was portraying the atmosphere traditionally endemic to all Unix and Linux discussions. You do not, of course, need to put up with the hubris. Instead, just read the man page.