And changing the security policy required changing the security manager itself

Chapter 4. The Security Manager

In the next three chapters, we're going to discuss how the sandbox of a Java application is implemented. The implementation of the sandbox depends on three things:

But the large body of pre−Java 2 programs dictates that the primary interface to system security −− that is, the security manager −− cannot change; otherwise, existing code that implements or depends on the security manager would become obsolete. Hence, the introduction of the access controller die the security manager −− it supplemented the security manager. This relationship is illustrated in. Typically, an operation proceeds through the program code into the Java API, through the securito the access controller, and finally into the operating system. In certain cases, however, the security manager may bypass the access controller. And native libraries are still outside the domain of either the security manager or the access controller (although the ability to load those libraries may be restricted).

Figure 4−1. Coordination of the security manager and the access controller

facets of Java's security story, but the role played by the security manager is of paramount importance in defining the security policy under which a particular program will operate.

On one level, the Java security manager is simple to understand, and it's often summarized by saying that it prevents Java applets from accessing your local disk or local network. The real story is more complicated than that, however, with the result that Java's security manager is often misunderstood.

package javasec.samples.ch04;

import java.applet.*;