The Problem of Script-Generated Files: Web Server Secrets, Part 5

Until now, everything works exactly as you’d expect. You create and upload your files; surfers surf them; all is well. Until, that is, you install a PHP or CGI script.

Still the Shared Departmental Thinking

Again, you need to think of your server as a shared departmental computer. Do you want your colleagues to be able to trash your files any time they have a mind to? Of course not. What about the ones who are not your colleagues? Do you want to allow anyone who has an account on that computer, to edit your personal files? Probably not.

On today’s servers, this might sound silly. Especially on a dedicated virtual server, where the only person there is you. On a shared server, security is tight. Most people are limited to ftp access, and they wouldn’t know how to find your files if they wanted to.

What’s important is the mind set. If you think like the departments did a generation ago, you’ll see what I’m getting at. Do you want the world at large to be able to overwrite your files?

Yes, actually, you do!

PHP and CGI Scripts Updating Files

You see, your PHP and CGI scripts fall in the category of “the world at large.” It’s not you running the script. Sure, you go to the URL, click the button to update, but it’s still not you!

Do you see why this is so? Your browser (which is showing you the button to click) is not logged into your server. You are a surfer. Your browser sends a request over to the Apache server software residing on your server. It’s Apache who figures out that you wish to update one of your own files.

From a Unix or Linux standpoint, however, you are not Apache and Apache is not you. You are two different users on the same computer. You’re not even part of the same departmental work group.

Can you see what this means? You’re probably several steps ahead of me at this point… but don’t worry, it will get tricky in just a moment!

Suppose your PHP or CGI script needs to update your index.html page. Your file has 644 permission:

-rw-r--r-- 1 genealogist users 747 Mar 30 19:21 index.html

That means you (the owner) can update the file, but the world at large (including the Apache server!) can not. You have a permissions problem. You need to change the file permissions to 666 (-rw-rw-rw-). Any file that your script needs to update, must have 666 permission.

Caveat. There is an important exception to the above rule, which I will explain a bit later.

Moving Files with CGI and PHP Scripts

What if your CGI script needs to create, delete, or move files? Create, delete, and move are directory operations. That means the directory must have 777 permission. If your directory has 755 permission (drwxr-xr-x), the script will fail to create the file. And, chances are, it will not tell you that it failed, let alone tell you why it failed.

Did you catch that? If the script does not have directory write permission, it won’t even know that something went wrong! It will blunder merrily along, and you’ll have no idea something is broken.

Would you believe that you now know more about how Unix and Linux files work than most script writers? Based on my own observations, it’s true!

Script-Created Files

You can create a file that the PHP or CGI script can’t touch. If you want the script to be able to read but not write the file, that’s 644 permission. You own the file, and have read/write permission – that’s the 6. The script falls in the “others” category, and thus has read-only permission – that’s the second 4 of the 644.

In the same way, the script can create a file that you can’t touch. If the script owns the file, and the file has 644 permission, you can read but not write the file. It’s a two-way street. You and the script are two different users on the same computer. You can each read the other guy’s files, and can update your own.

Finally – finally – we can wallow in the delicious subtleties of Unix and Linux, which will bite you good and hard. Even some of the server admins don’t seem to understand this!

Still About Departmental File Sharing

Once again, consider your colleague in some other department. You and she are using the same computer. You need her to drop a copy of one of her files into your directory. Therefore, you give her an open directory like this:

drwxrwxrwx 2 genealogist users 4096 Mar 31 12:40 tmp

777 directory permission means that she can create a file in your directory, or copy a file into your directory, which amounts to the same thing. After she’s dropped the file into your tmp directory for you, your tmp directory might look like this:

drwxrwxrwx 2 genealogist users 4096 Mar 31 12:42 .
drwxr-xr-x 5 genealogist users 4096 Mar 31 12:40 ..
-rw-r--r-- 1 gopher      squid    8 Mar 31 12:42 info.html

(In Unix or Linux, . refers to the current directory, and .. refers to one directory up – that is, the current directory’s parent directory.)

Do you see the problem we have here? gopher was kind enough to provide me the file info.html. I can read the file, but I can’t update it! The file has 644 permission, which would be just fine if I owned the file.

Do you see that I can rename, copy, or delete the file? Rename, copy, and delete require directory write permission, and I have plenty of that. Well, copy also requires that I read the file – but I can do that. I just can’t edit it!

So… what can I do? I can’t change the file’s permissions, because I don’t own the file. That’s right! The file is in my directory. But I can’t touch it (except to delete it), because I don’t own it. Only the file owner (or the server admin) can change its permissions.

A generation ago, this was easy. Give gopher a call, and ask her to open up the file. No problem; it literally happened all the time. But what if the file owner is your PHP or CGI script? Who are you going to call?

Hmm… well, let’s think about this. Do you actually care? Are you supposed to be editing that script’s files? Probably not – in which case, just leave the file alone, and everything will be fine.