Previous Table of Contents Next Read-Only A read-only file is easy enough to check. If your workstation is Windows, right-click the file, go to Properties, and see whether the Read-Only check box is checked. If it is, somebody has set it this way. You'll have to go find out why (you can find out who owns the file in the same dialog box). Blanket Security You'll want to check pertinent files and directories to see that the user can, in fact, access the files in question. In UNIX, you'll want to look at the full properties of the file and make sure that the file is readable or writable by the user in question. Here's an example of a file's full properties: ls -la mysecretfile -rwxrwx--- 1 monkey root 140 Nov 14 1997 mysecretfile UNIX file properties are usually the same, even between versions of UNIX. There are three potential clusters of rwx along the left side, each meaning "read, write, or execute permission" for the cluster. The first cluster means "user permission," the second means "group permission", and the third means "world" permission. In this example, the mysecretfile file is owned by the user monkey, and it belongs to the group root. It's 140 bytes long and was last modified on November 14, 1997. monkey has full read, write, and execute permissions and anybody in the root group can read, write, or execute this file, but the rest of the world cannot do anything to this file. Using a Windows desktop, you can check the file properties. Some network clients, such as Novell's client, will add a tab to the file properties, as in Figure 18.2, where you can check file permissions. Simply right-click any file and select Properties from the menu that appears. [18-02t.jpg] Figure 18.2 File properties, as viewed on a Windows 95 workstation with the Novell IntranetWare client. If you know that one user can get to the file but another user can't, you should compare the groups to which the users belong. It's not common practice to assign user-level permissions to files that groups of people need to get to (which works to your advantage). When all else fails (and you're starting to tear your hair out), you can make the user into a super-user equivalent and try again. (You can do this under Novell by assigning Admin to the user's Security Equivalences tab in the NWAdmin; NT users can be added to the Domain Administrators group as well as the Administrators group.) If the operation succeeds after you've done this, you know that you have a security-related issue and can then pursue it further. ______________________________________________________________ Every security person on the face of the earth is going to have conniptions over me telling you to do this. There is danger here, Will Robinson. I'm not advocating the practice of normal users running as a supervisor or administrator equivalent-that would be nuts, and it would cause you more problems than you'd know what to do with. (Can you imagine Traci in HR with the power to delete your server's hard drive? I'm shuddering.) I am saying that you can rule out security-related problems this way. If you temporarily allow a user these rights-and then take them away when you're done-this is a powerful method for ruling out (or ruling in) security problems. Here's the bottom line: As long as you don't forget to take away the security rights when you're done, and you do this for a short, controlled period of time, you should be okay. ______________________________________________________________ Flock o' Locks File locks can cause all sorts of wondrous problems. For example, some backup programs can't deal with a user who has a file open-which causes all sorts of backup problems. Some email programs or database engines keep their files open even while not in use-which causes backup programs to skip them while backing up. Come again? Wouldn't you rather have any backup-even risking that the file changed in the middle-than no backup of a file? The solution to this is to purchase a backup program with an open file manager, which avoids this sort of thing (a problem found in Novell and Windows, but not UNIX). Many problems, though, are caused by users being in files. For example, suppose I'm trying to update a terminal emulation program early in the morning, say, at 5:30 or 6:00. I attempt to install the update, only I get a Can't write to file error in the install program. The install program is helpful enough to tell me that it thinks that someone else may be using the file, but that's about it. Alternatively, I might get a call from a user who is trying to update a file, and WordPerfect is telling her that she can only open the file as a read-only file. In both of these cases, if I know the name of the file, I can use server utilities to find out who's using it. Under NetWare, go to the Monitor's File Open|Lock Activity menu, navigate the volumes and directories, and pick the file, which would show you the server connections that have locks on the files. Then go to Connection Information and scroll down to that connection number, which tells you the user name. Previous Table of Contents Next