Server Secrets

By
Old Tom

OT Scripts

Part Three: Creating the Untouchables

CGI-Created Files

You can create a file that the 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, which will bite you good and hard. Even some of the server admins don't seem to understand this!

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 oldtom 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 directory might look like this:

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

(In unix, . 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 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.

Interlude

Well. This was sadistically boring, as promised. Let me remind you of 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 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.

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!

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 works.

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 CGI script owns the file. That file can be edited by your script, so we have no problem.

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 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!

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 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 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 that I showed you above.

Next week is Part 4: Which Way to Swing.

Warning
Unix 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 endemic to all unix discussions. You do not, of course need to put up with such crap. Instead, just read the man page.

Old Tom