Sun Java Solaris Communities My SDN Account Join SDN
 
Tutorials & Code Camps

Writing Your Own SecurityManager

 
Training Index


Help | Solution | API Docs | Expected Output
Course Notes | Magercises | Module Intro

Skeleton Code

This magercise demonstrates the creation of a custom security manager. As you cannot replace the security manager within an applet, this exercise will create an application. The security manager does not permit the application from reading or writing files from disk, unless the filename ends with the extension .tmp.

See the Managing Security course section for additional information.

Perform the following tasks:

  1. When creating your own security manager, you have to subclass SecurityManager. The java.lang.SecurityManager implementation throws security exceptions when attempting any operation. So, instead of subclassing, overriding everything, and doing something special for the methods related to file access, you'll create a null security manager that overrides everything and doesn't throw any security exceptions. This involves compiling the NullSecurityManager.java file provided.

  2. Next, save the MySecurityManager.java skeleton. This is an empty subclass of the NullSecurityManager just created. You will need to fill in the checkRead and checkWrite methods next as they are the methods used to restrict file access.

  3. Starting with checkWrite, there are two varieties to look into: public void checkWrite(FileDescriptor fd) and public void checkWrite(String filename). With the FileDescriptor variety, you do not have to do anything. When creating an object that has a method that returns a FileDescriptor, the object will do the appropriate security checks before a FileDescriptor is available.

    So, this leaves you with overriding public void checkWrite(String filename). If the filename provided in the method does not end with the file extension .tmp, throw a SecurityException.

  4. There are three varieties of checkRead to worry about: public void checkRead(FileDescriptor fd) public void checkRead(String filename), and public void checkRead(String filename, Object context). As with checkWrite, you can ignore the FileDescriptor variety. For the two argument variety, this acts like a proxy where the context parameter is the results of a previous call to SecurityManager.getSecurityContext. This allows one object to check access for another object, like in the case of RMI, where the other object could reside with another virtual machine. In this magercise's particular case, the context is irrelevant, only the filename is important. So, just have the two argument filename variety call the one argument filename variety.

  5. For the public void checkRead(String filename) variety, have the method throw a SecurityException if the filename parameter doesn't end with .tmp.

  6. That's all there is to MySecurityManager. Compile the class now.

  7. The SMTester.java program tests out the new security manager. The program includes tests for reading and writing the files joe.txt and joe.tmp, before and after a security manager is installed. It is your job to install the security manager previously defined.

  8. Compile and run the program. The program doesn't read/write to any files. Instead, it uses File.exist and File.canWrite to see if it has permissions to read or write.

The task numbers above are linked to the step-by-step help page. Also available is a complete solution to the problem, and a demonstration of the expected behavior.

Copyright © 1998 MageLang Institute. All Rights Reserved.