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. Youll have to go find out why (you can find out who owns the file in the same dialog box).
Blanket Security
Youll want to check pertinent files and directories to see that the user can, in fact, access the files in question.
In UNIX, youll 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. Heres an example of a files 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. Its 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 Novells 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.
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 cant, you should compare the groups to which the users belong. Its 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 youre 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 users 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 youve 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. Im not advocating the practice of normal users running as a supervisor or administrator equivalentthat would be nuts, and it would cause you more problems than youd know what to do with. (Can you imagine Traci in HR with the power to delete your servers hard drive? Im shuddering.)I am saying that you can rule out security-related problems this way. If you temporarily allow a user these rightsand then take them away when youre donethis is a powerful method for ruling out (or ruling in) security problems.
Heres the bottom line: As long as you dont forget to take away the security rights when youre 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 cant deal with a user who has a file openwhich causes all sorts of backup problems. Some email programs or database engines keep their files open even while not in usewhich causes backup programs to skip them while backing up. Come again? Wouldnt you rather have any backupeven risking that the file changed in the middlethan 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 Im 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 Cant 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 thats 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 whos using it.
Under NetWare, go to the Monitors 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 |