8.5 ProtectionDomains

8.5 ProtectionDomain s

When a class is loaded into the JVM by the appropriate Java 2 ClassLoader , the CodeSource of that class is mapped to the Permission s granted to it by the current policy. The Permission s are first organized into PermissionCollections , so that homogeneous Permission s are grouped together, and then the various PermissionCollection s are organized into a Permissions object, which becomes a heterogeneous set of PermissionCollection s, as depicted in Figure 8.4 on page 259.

These two pieces of information ”the CodeSource and the Permissions object ”are stored by the ClassLoader in a java.security.ProtectionDomain object, graphically represented in Figure 8.7. It is, therefore, the responsibility of the ClassLoader to interrogate the Policy object currently in effect and to build the ProtectionDomain for each class loaded into the system, based on the class's CodeSource . A set of Permission s is bound to the ProtectionDomain when it is constructed . Starting with Java 2 SDK V1.4, to support dynamic security policies, a ProtectionDomain can also be constructed such that it is dynamically mapped to a set of Permission s by the current Policy whenever a Permission is checked. ^[1]

^[1] Prior to Java 2 SDK V1.4, ProtectionDomain s were cached and could not be refreshed. A change in the Java system's policy did not reflect in a change in the ProtectionDomain s. This was a limitation for systems in which the Policy was subject to changes because in order to refresh the ProtectionDomain s, it was necessary to restart the JVM.

Figure 8.7. Graphical Representation of a ProtectionDomain

8.5.1 The implies() Method in the ProtectionDomain Class

Each ProtectionDomain defines an implies() method that takes a Permission object argument and returns a boolean . This boolean value indicates whether the CodeSource encapsulated in the ProtectionDomain has been granted the Permission passed as a parameter. If the return value is true , classes with that CodeSource are allowed to perform the action guarded by that Permission .

When implies() is invoked on a ProtectionDomain , the ProtectionDomain turns the request to the implies() method on the Permissions object that it encapsulates, as explained in Section 8.2.4 on page 260. The implies() method of the ProtectionDomain returns true if and only if the implies() method of one of the Permissions objects that it encapsulates returns true .

8.5.2 System Domain and Application Domains

Java 2 system classes are treated in a special way. Because they are considered fully trusted, they have a prebuilt ProtectionDomain , called the system domain , that grants them AllPermission . The system domain is also known as the null ProtectionDomain because, from an implementation point of view, the primordial class loader, which is responsible for loading the system classes, does not even build a ProtectionDomain for them, and calling getProtectionDomain() on one of those Class objects returns null . This is done for performance purposes. For the same reason, AccessController does not even check that a class in the system domain is granted the Permission to perform a restricted action; AllPermission is implicitly granted.

Nonsystem classes are said to belong to an application domain . At JVM start-up, one and only one system domain always contains the system classes, and zero or more application domains contain the nonsystem classes. To be precise, there are as many application domains as the nonsystem CodeSource s.

8.5.3 Relation between Classes, ProtectionDomain s, and Permission s

Based on how ProtectionDomain s are defined, we can conclude the following.

• All the classes with the same CodeSource belong to the same ProtectionDomain .

• Each class belongs to one and only one ProtectionDomain . The ProtectionDomain depends on the class's CodeSource and the Permission s granted to the CodeSource .

• Classes that have the same Permission s but are from different CodeSource s belong to different ProtectionDomain s.

The Java application environment maintains a many-to-one mapping from classes to their ProtectionDomain s and a many-to-many mapping from those ProtectionDomain s to their Permission s, as shown in Figure 8.8.

Figure 8.8. Class/ ProtectionDomain and ProtectionDomain / Permission Mappings