The Main Event: Web Server Secrets, Part 6

Let’s look back at the important points before we proceed to the main event. You’d be amazed at how many server admins don’t really understand the stuff you’re wading through here!


For a PHP or CGI script to find, create, delete, or move files, the script needs suitable directory permission. This usually means that if the script is doing stuff in the directory, the directory permission needs to be set to 777. If stuff is mysteriously failing to happen, make sure the directory is where the script thinks it is, and that it’s set to 777.

For a CGI script to be treated as a script, the script itself needs execute permission, i.e., 755.

If a file needs to be updated (e.g., a data file), the file must be owned by the script, or have 666 permission. If a file needs to be created, it’s the directory which must have 777 permission. If the script creates the file, the script owns the file, so the actual file permission won’t be an issue (until we hit the main event!).

If you need to make all of your files and directories script-accessible, log into your server via telnet or ssh, and execute the following command:

find . -exec chmod ugo+rw {} \\;

That command will take care of the current directory and all subdirectories.

Some Unix and Linux servers allow a -R (recursive) option. This command accomplishes the same as the above:

chmod -R ugo+rw .

The Main Event

Finally! The Event has arrived! This is where things get messy, and this is where I get the calls for help.

What happens when you change servers, or restore all of your files from a backup copy? Perhaps your webspace provider put you on a different server, or perhaps you moved the whole shootin’ match to a different webspace provider. Perhaps the new server admin took care of the move for you. He took care of the search and replace, to get the new pathnames correct.

In every one of these cases, we have the same problem, and it’s a messy one. Do you see the problem yet? I’ll be quite pleasantly surprised if you do. Many server admins don’t see the problem either!

Caught in the Middle

This problem is not the admins’ fault, as you’ll see. The admins are merely caught in the middle. The problem is not really the programmer’s fault either, by the way. The problem is just a natural outcome of how Unix and Linux work.

Do you recall that file info.html owned by gopher? The file with 644 permission? Let’s assume that Apache is actually user gopher. In other words, your PHP or CGI script owns the file. That file can be edited by your script, so we have no problem.

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

Now for the Main Event. Let’s just suppose that somehow that file magically became owned by you rather than by the script. It still has 644 permission – but suddenly you can edit the file, and your PHP or CGI script can not. If the script needs to edit the file, can you see how this can be a problem? You’ve swapped horses in midstream. You’ve yanked the rug out from under it. You changed the rules in the middle of the game. Your script might not recognize what just happened – and therefore you’ll have no clue that something is wrong.

Give the file 666 permission rather than 644 permission, and all is well. Do you see why this is so? With 666 permission, the script can edit the file regardless of who actually owns the file.

Do you see the problem? If you somehow magically take ownership of the script’s files, the script is screwed. It’s your script, so that means that you just screwed yourself!

File Restore Changes Permissions

So. How do you screw yourself in such a fashion? You change servers. It’s that simple.

How you changed servers, or why you changed servers, doesn’t matter in the least. Perhaps your server admin upgraded you to a brand-new virtual dedicated server. Perhaps you changed ISPs. That does not matter – it’s the move itself that killed your script. You will have the same problem, by the way, if you had to restore your files from a backup. Disasters happen; that’s why we make backups; recovering from the disaster can kill your script.

How do you make a backup? You make a copy of all your files and put them somewhere. Right? If you can’t read the file, you can’t make a backup copy of that file. This makes sense, right?

What if the CGI script owns the file? As long as you can still read the file, you can make the backup. That’s what’s important. So far, so good.

What if we move servers, though? How exactly do you move servers? What you do is, make a backup copy of all your stuff. Then, you unload all that stuff onto your new server. You are restoring your stuff from a backup. Sure, it’s a new server, but from a Unix or Linux standpoint it’s a plain ole file restore.

When you do the file restore, you’re screwed. It’s that simple! And I can guarantee you there are plenty of server admins out there who will happily move your stuff, not realizing that they’re killing your script in the process.

What just screwed you? File ownership! When you restore the files to your account, the files become owned by you. Because they’re suddenly yours, you’re screwed.

Remember info.html? It has 644 permission – which means that only the owner can edit it. When it was owned by the script, all was well. But now that you own it thanks to the server move, the script is broken.

Okay, so you’re screwed. How do you fix the problem? You can go in with ftp, and individually change the permissions on each directory, and each file, that’s affected. Or, you can use the find instruction (or chmod -R instruction) that I showed you above.