A Stack Inspection that Says "Yes"

As the first stack inspection example, consider the Example2a application:

// On CD-ROM in file security/ex2/Example2a.java
import com.artima.security.friend.Friend;
import com.artima.security.stranger.Stranger;

// This succeeds because everyone has permission to
// read answer.txt
class Example2a {

    public static void main(String[] args) {

        TextFileDisplayer tfd = new TextFileDisplayer("question.txt");

        Friend friend = new Friend(tfd, true);

        Stranger stranger = new Stranger(friend, true);

        stranger.doYourThing();
    }
}

The Example2a application creates three Doer objects: a TextFileDisplayer, a Stranger, and a Friend. The TextFileDisplayer constructor is passed the String, "question.txt". When its doYourThing() method is invoked, it will attempt to open a file named question.txt in the current directory for reading and print its contents to the standard output. The Friend object's constructor is passed a reference to the TextFileDisplayer object (a Doer) and the boolean value true. Because the passed boolean value is true, when Friend's doYourThing() method is invoked, it will directly invoke doYourThing() on the TextFileDisplayer object. The Stranger object's constructor is passed a reference to the Friend object (also a Doer) and the boolean value true. Because the passed boolean value is true, when Stranger's doYourThing() method is invoked, it will directly invoke doYourThing() on the Friend object. After creating these three Doer objects, and hooking them together as described, Example2a's main() method invokes doYourThing() on the Stranger object and the fun begins.

When the Example2a program invokes doYourThing() on the Stranger object referenced from the stranger variable, the Stranger object invokes doYourThing() on the Friend object, which invokes doYourThing() on the TextFileDisplayer object. TextFileDisplayer's doYourThing() method attempts to open and read a file named "question.txt" in the current directory (the directory in which the Example2a application was started) and print its contents to the standard output. When TextFileDisplayer's doYourThing() method creates a new FileReader object, the FileReader's constructor creates a new FileInputStream, whose constructor checks to see whether or not a security manager has been installed. In this case, the concrete SecurityManager has been installed, so the FileInputStream's constructor invokes checkRead() on the concrete SecurityManager. The checkRead() method instantiates a new FilePermission object representing permission to read file question.txt and passes that object to the concrete SecurityManager's checkPermission() method, which passes the object on to the checkPermission() method of the AccessController. The AccessController's checkPermission() method performs the stack inspection to determine whether this thread should be allowed to open file question.txt for reading.

Figure 3-6 shows the call stack when the AccessController's checkPermission() method is invoked. In this figure, each frame of the call stack is represented by a horizontal row that is composed of several elements. The leftmost element in each stack frame row, which is labeled "class," is the fully qualified name of the class in which the method represented by that stack frame is defined. The next element to the right, which is labeled "method," gives the name of the method. The next element, which is labeled "protection domain," indicates the protection domain with which each frame is associated. Farthest to the right is an arrow that shows the progression of the AccessController's checkPermission() method as it checks whether each stack frame has permission to perform the requested action. Just to the left of the arrow is a number for each stack frame. Like all images of the stack shown in this book, the top of the stack appears at the bottom of the picture. Thus, in Figure 3-6, the top of the stack is the frame numbered 10.

Figure 3-6. Stack inspection for Example2a: all frames have permission.

The protection domain column of the stack diagram shown in Figure 3-6 shows each frame associated with one of four protection domains, named "FRIEND," "STRANGER," "CD-ROM," and "BOOTSTRAP." Three of these protection domains correspond to grant clauses in policyfile.txt. The FRIEND protection domain corresponds to the grant clause that gives permission to any code signed by friend to read question.txt and answer.txt. The STRANGER protection domain corresponds to the grant clause that gives permission to any code signed by stranger to read question.txt. The CD-ROM protection domain corresponds to the grant clause that gives permission to any code loaded from the "${com.artima.ijvm.cdrom.home}/security/ex2/" directory to read question.txt and answer.txt. The fourth and final protection domain, named BOOTSTRAP, doesn't correspond to any grant clause in policyfile.txt. Rather, the BOOTSTRAP protection domain represents the permissions granted to any code loaded by the bootstrap class loader, which is responsible for loading the class files of the Java API. Code in the BOOTSTRAP protection domain is granted java.lang.AllPermission, which gives it permission to do anything.

To get the Example2a application to demonstrate stack inspection as intended, you must start the application with an appropriate command. When using the java program from the Java 2 SDK version 1.2, the appropriate command takes the form:

java -Djava.security.manager -Djava.security.policy=policyfile.txt
-Dcom.artima.ijvm.cdrom.home=d:\books\InsideJVM\manuscript\cdrom -cp
.;jars/friend.jar;jars/stranger.jar Example2a

This command, which is contained in the ex2a.bat file in the security/ex2 directory of the CD-ROM, is an example of the kind of command you'll need to use to get the example to work. By defining the java.security.manager property on the command line, you indicate you want the concrete SecurityManager to be automatically installed. Because the Example2a application doesn't install a security manager explicitly, if you neglect to define the java.security.manager property on the command line, no security manager will be installed and the code will be able do anything. The -cp argument sets up the class path, which causes the virtual machine to look for class files in the current directory and in the friend.jar and stranger.jar files in the jars subdirectory. The com.artima.ijvm.cdrom.home property indicates the directory in which Doer, Example2a, and TextFileDisplayer are located. This property is used by the third grant clause in policyfile.txt, which corresponds to the protection domain named "CD-ROM." As a result, types Doer, Example2a, and TextFileDisplayer will be loaded into the CD-ROM protection domain and granted permission to read to both question.txt and answer.txt. To execute Example2a on your own system, you must set the com.artima.ijvm.cdrom.home property to the security/ex2 directory of your CD-ROM, or to whatever directory you may have copied the security/ex2 directory from the CD-ROM.

When the AccessController performs its stack inspection, it starts at the top of the stack, frame ten, and heads down to frame one, which is the frame for the first method invoked by this thread, main() of class Example2a. In the case of the Example2a application, every frame on the call stack has permission to perform the action: to read the file "question.txt". This is because all four protection domains represented on the call stack -- FRIEND, STRANGER, CD-ROM, and BOOTSTRAP -- include or imply a FilePermission for reading question.txt in the current directory. When the AccessController's checkPermission() method reaches the bottom of the stack without having encountered any frames that don't have permission to read the file, it returns normally, without throwing an exception. The FileInputStream goes ahead and opens the file for reading. The Example2a application reads in the contents of question.txt and prints them to the standard output, which looks like this:

Too what extent does complexity threaten security?