ProtectionDomains

8.5 ProtectionDomains

When a class is loaded into the JVM by the appropriate Java 2 ClassLoader, the CodeSource of that class is mapped to the Permissions granted to it by the current policy. The Permissions are first organized into PermissionCollections, so that homogeneous Permissions are grouped together, and then the various PermissionCollections are organized into a Permissions object, which becomes a heterogeneous set of PermissionCollections, as depicted in Figure 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. 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 Permissions 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 Permissions by the current Policy whenever a Permission is checked.^[1]

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

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.

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 CodeSources.

8.5.3 Relation between Classes, ProtectionDomains, and Permissions

Based on how ProtectionDomains 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 Permissions granted to the CodeSource.

• Classes that have the same Permissions but are from different CodeSources belong to different ProtectionDomains.

The Java application environment maintains a many-to-one mapping from classes to their ProtectionDomains and a many-to-many mapping from those ProtectionDomains to their Permissions, as shown in Figure.