One of the most important and pervasive differences between Windows 2000 and UNIX is the manner in which they handle permissions and security. These differences are subtle and frequently lead the unwary to make false assumptions. Because Chapters 18 and 19 have already explained in great detail how Windows 2000 handles security, we'll spare you here, but if you're going to coexist with UNIX servers, you need to understand how UNIX handles security to avoid problems. Let's look at a UNIX file listing first, and then examine symbolic links, privilege levels, and permissions.
A UNIX file listing might look something like this:
-rwxr-x—x 2 charlie dba 2579 Aug 30 15:49 resize
This listing tells us virtually all we need to know about the security and permissions of the file we're looking at. Let's start at the left of the line and work our way across to see what we've got and what it means—and how it compares to Windows 2000.
The first dash (-) tells us that this listing is not a directory. If it were a directory, a "d" would be in that place instead. UNIX treats a directory as simply another file, although a special one, and the permissions have a slightly different meaning when referring to a directory as opposed to a file. We'll cover directory permissions in a bit, but let's stay with regular files for now.
The next three characters correspond to the permissions of the file owner—who can be someone other than the original creator because UNIX allows a user to "give" a file to another user. The "r" indicates that the owner has the right to read the file; the "w" means that she or he can write to it, delete it, or otherwise modify it; and the "x" allows the owner to execute the program.
In Windows 2000, the operating system decides whether a program is executable based on the filename. If the filename has an extension of .COM, .EXE, .BAT, or .CMD, it can be executed, assuming the user has the appropriate permissions. In UNIX, no association exists between the extension and whether the file is executable. In fact, most UNIX files have no extension at all. The only determinant of whether a file is executable is the permission of the file. So, although it might be the convention on a particular system to always name shell scripts (the UNIX equivalent of a batch file) with a name that ends in .sh or .ksh, this has no actual meaning. The file must be given the execute permission before it can be executed.
The fifth, sixth, and seventh characters correspond to the permissions of members of the same group as the owner of the file. The "r" indicates that members of the group can read the file (or perform actions that leave it unchanged, such as copying it); the dash indicates that they do not have permission to write to it, delete it, or otherwise modify it; and the "x" gives them the ability to execute the program.
Finally, the last three characters of the first group correspond to the permissions of the rest of the world. The initial dash indicates that these users don't have the right to read the file, or in any way look at the contents, nor do they have permission to copy the file. The second dash indicates that they don't have permission to change, modify, or delete the file, and finally, the last "x" indicates that they can execute the file, if executing doesn't actually require a read.
UNIX has only three basic permissions: Read, Write, and Execute.
The next character, the number 2, indicates that there are two hard links to the file. A hard link gives the exact same file another name. There is still only a single actual file stored on the hard disk, but there are two directory entries pointing to the file. There are no practical limits to the number of hard links that can exist to a single file, but all links to the file must exist on the same file system.
The next two groups in the listing are the owner of the file, "charlie," and the group for the file, "dba." These are normally user and group names, but they could also be a number if either the owner or group of the file doesn't actually have an account on the system.
Next we have the size of the file (2579 bytes in this case), the date and time when the file was created or last updated, and the name of the file—actually, the directory entry for the file that corresponds to this hard link to the file. Note that no link has any preference over any other. There is nothing significant about which name comes first; all are treated equally. Deleting one link does not delete the file—just that reference to it. Any other versions of the file remain.
UNIX supports both hard links and symbolic links. Symbolic links are analogous to Windows 2000 shortcuts but with several differences. The most important difference is that in UNIX when you access the symbolic link, you actually access the file it points to, not the link itself. For example, if you edit a symbolic link to a text file, you're actually editing the original text file. With a Windows 2000 shortcut, you can use the shortcut only to start an executable file or to open a folder.
A symbolic link differs from a hard link in that the actual file has precedence over any of the symbolic links to it. In fact, the listing for a symbolic link to our earlier resize file makes it immediately clear that this is a symbolic link, not a hard link:
lrwxrwxrwx 1 charlie dba 2579 Aug 30 15:49 resize -> /u/cpr/resize
As you can see, the listing not only begins with the letter "l" in the first position, but it actually shows where the link is pointing. You'll notice that the two filenames are identical. Although this isn't a requirement, it is the most common use of symbolic links—to make a file appear as if it were in one place when it actually resides elsewhere.
Another feature of a symbolic link that distinguishes it from a hard link is that it can cross file systems and even machines. You can have a symbolic link that points to a file that resides on a completely different computer.
If you copy a file on top of a symbolic link, the link is broken. Your new file actually replaces the link with the file. The original file still exists, however, making the duplication of files confusing at best.
Traditionally, UNIX divides the world into only three types of users: the owner of a file, a member of the same group as the owner, and all the rest of the world. These three privilege levels are called owner, group, and other. So far, so good. This sounds a lot like Windows 2000, right? A big difference is in the second privilege level: group.
On UNIX systems with traditional security, a user is active only in a single group at a time. When that user creates a file, the file has permissions for the group based strictly on the current group of the file creator. This situation can have interesting and subtle complications when compared to the Windows 2000 methodology. If a user's primary logon is to one of the standard groups, things generally behave as you would expect. However, when a user belongs to a specialized group with limited membership and creates files while that group is the active group, the ability of users outside the group to access the file could be constrained.
A user who isn't an active member of the group that owns a file and who isn't the actual owner of the file is in the other privilege level. This arrangement is essentially the same as the Windows 2000 Everyone group. A user in the other category has no permission to access the file except what every other user has.
The UNIX Super User
In discussions of UNIX security, keep in mind one overriding principle: the root user (sometimes called the super user) has access to everything. In the Windows 2000 world, you can easily set a file or directory so that even those users with administrative privileges don't have access without changing the ownership of the file, but in the UNIX world, that restriction doesn't exist. Not only that, but the super user can even change identities to have the same identity as you without knowing your password.