Server Secrets

By
Old Tom

OT Scripts

Part Two:
One of the Coolest Things in Unix

Three Digits
Each file or directory has three permissions (rwx) each, for the file owner (user), group, and others. That's why a unix directory listing shows three sets of permissions: drwxrwxrwx for a directory, and -rwxrwxrwx for a plain file.

Unix is all about abbreviations. Vowels are never used when something unpronounceable will do. The first letter will often be used in lieu of the entire word. cp stands for copy, od stands for octal dump, yes stands for you're going to be sorry you asked.

So. If you can get a letter to stand for a word, why not have a digit stand for a series of letters each standing for a word or phrase? To a unix person, that's called efficiency, and therefore the very height of coolness.

One of the coolest things in unix, is file permissions. (I'm just giving the tip of the iceberg, you will recall... if you happened to have observed how directory set group id changes from s to S with an nfs mount, you'd begin to appreciate ultimate coolness. However, we'll leave total coolness for another day.)

Read permission is assigned a value of 4. Write permission is 2, and execute permission is 1. Thus rwx is 7, rw- is 6, r-x is 5, r-- is 4, and --x is 1. When you slap user, group, others' permissions together, you have truths such as rwxrwxrwx is 777, rw-r--r-- is 644, rw-rw-rw- is 666, rwxr-xr-x is 755, and rwx--x--x is 711.

But, what does this mean??? Finally, I can explain!

Apache Server
On your server, you are one of the users. This makes sense, right? You have an ftp login, and the files in your domain are (mostly) owned by yourself - that is, they're owned by that ftp login. On a server, the "group" concept really doesn't matter. Either everybody else is in your group, or nobody is. But it's unix, and that means the "group" part of the permission stuff is still there.

Meanwhile, the Apache server itself, is a different user. The server itself owns its own files - and does not own your files. In the choice of "user, group, others", the server falls in the "others" category. (With one important exception; I'll get to that exception in just a bit!)

When a surfer blows on in to look at your awesome web page with 300k of fast-loading graphics, what actually happens? That surfer doesn't actually log on to your server. Instead, that surfer's browser sends a request to the Apache software which is logged in to your server. More precisely, the Apache software resides on your server, and listens for requests.

When Apache sees that surfer's request, it figures out which of your files to grab, and feed to that surfer. Can Apache grab everything you've got? No, it can't. First, it's restricted by the server configuration files, and by your .htaccess files. Second, it's restricted by your unix file permissions. We'll ignore that first restriction for now, and remain focused on the second.

If the file permission is 644 (-rw-r--r--), that means that "others" can read the file but not overwrite it. Apache is one of those others. What about the directory? Every file is in some directory, and therefore directory permission always counts. If the directory permission is 711 (drwx--x--x), the server can grab the file. If the directory permission is 700 (drwx------), the server can't touch it.

CGI Scripts
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 CGI script.

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 server, where the only person there, is you. On a shared server (i.e., a virtual host), 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!

You see, your 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 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 CGI script needs to update your index.html page. Your file has 644 permission:

-rw-r--r-- 1 oldtom 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.

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, or 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 files work, than most script writers? Based on my own observations, it's true!

Next week is Part Three: Creating the Untouchables.

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