Reading a File:

Let's look at an instance to known how the security model works in practice. This instance concentrates on what happens in the third layer, for two reasons: A lower two layers sometimes deal along with a few rather esoteric issues of type theory, and they are not inside the programmer's control.  At the top layer, alternatively, is relatively straightforward and can be controlled through Java application programmers.

Assume that the Snark applet has been loaded onto your system and needs to read one of your files-say, diary.doc. For open the file for reading, Snark has to use one of the core Java classes-in particular, FileInputStream and RandomAccessFile in the java.io package. Since those core classes are an elements of the security model, before those permit reading from that particular file that ask the system security manager whether it's okay. These two classes create the request in their constructors; FileInputStream uses code such as this:

// Gain access to the system security manager.

SecurityManager security = System.getSecurityManager();

if (security != null) {

// See if reading is permit. If not, the security manager will

// throw a SecurityException. The variable "name" is a String

// holding the file name. security.checkRead(name);

}

// If there is no security manager, anything goes!

The security manager is found by using one of the static methods in the System class. Everything is permitted if there is no security manager; if there is a security manager that is queried to see whether this access is permitted. The SecurityManager.checkRead() method returns if everything is fine; or else, it throws a SecurityException. Since  this  code  appears  in  a  constructor,  and  since  the exception isn't caught if the constructor never finished, and the FileInputStream object can't be created.

The SecurityManager class, an abstract class from that all application security managers are derived, holds various native methods which can be used to inspect the current state of the JVM. Within particular, the execution stack-the methods in the procedure of executing whenever the security manager is queried-can be examined in detail. A security manager could therefore tell that classes are included in the current request, and that can decide whether all those classes could be trusted along with the resource being requested.

Within the Snark instance, the security manager examines the execution stack and sees various classes, involving Snark. Which means something to us, but it possibly doesn't mean a lot to the security manager. Within particular, the security manager has probably never heard of a class called Snark, and presumably it doesn't even know that Snark is an applet. Since that's the actually important piece of information: if one of the classes currently on the execution stack is category of an applet or a few other untrusted, dynamically loaded program, then granting the request could be dangerous.

Currently, the security manager gets a few help. To each class on the execution stack, it can determine that class loader is responsible for which class. Class loaders are special objects that load Java bytecode files into the virtual machine. One of their responsibilities is to keep track of where every class came from and other information which could be relevant to the application security policy. Whenever the security manager consults Snark's class loader, the security manager learns (between other things) that Snark was loaded from the network. Finally, the security manager knows sufficient to decide that Snark's request should be rejected.