In addition to the methods of the security manager class that we just examined, a second way by which the security manager can enforce policies is to ask that the class loader for a particular class provide more information on which the security manager may base its decision. This technique requires a coordination between the security manager and the class loader; there is no standard interface by which this information may be obtained (nor is there a limit to the type of information that may be exchanged). The details of the interface are completely at the discretion of the application developer. This technique is useful for both 1.1-based and (to a lesser extent) 1.2-based security managers.
In the last section, we showed an example of the
checkWrite() method that threw a security
exception only if there was a class loader on the stack; this
effectively prevented any class that was loaded from the network from
opening a file in order to write to it. A more sophisticated policy
would be to allow certain classes loaded over the network to write
files, but not other classes. If you recall our example from Chapter 3, XYZ Corporation is using a customized class loader that allows their applications to read classes both from the web server on which the application is hosted and from the centralized administration server. XYZ Corporation might want to establish a security policy whereby classes that are loaded from the administration server can ...