The Permissions Class Permissions

When the new policy is installed, it will only affect code sources that have not yet been established. To use this technique, you must install a policy file and then load classes through a new class loader; only those classes will be subject to the policy file that youve just installed. You may also specify administratively which policy class to use by changing the policy.provider entry in the java.security file. By default, that entry is: policy.provider=sun.security.provider.PolicyFile So you can change sun.security.provider.PolicyFile to javasec.samples.ch05.MyPolicy , and that will be the default policy. But the MyPolicy class must reside in the boot classpath of the virtual machine. That means that in order to use this technique, you must either add MyPolicy.class to the rt.jar file, or you must run the virtual machine with the appropriate argument to specify the boot classpath. This argument is nonstandard and is subject to change, but in 1.3 to load the MyPolicy class from filespolicy youd use this command fragment: piccolo java −Xbootclasspath:filespolicy ...other args... Nonetheless, installing the policy file through the java.security file is far easier on developers since it will apply to all classes, regardless of their class loader.

5.4 Protection Domains

A protection domain is a grouping of a code source and permissions −− that is, a protection domain represents all the permissions that are granted to a particular code source. In terms of the policy files that we looked at in Chapter 2, a protection domain is one grant entry. A protection domain is an instance of the ProtectionDomain class java.security.ProtectionDomain and is constructed as follows: public ProtectionDomainCodeSource cs, PermissionCollection p Construct a protection domain based on the given code source and set of permissions. When associated with a class, a protection domain means that the given class was loaded from the site specified in the code source, was signed by the public keys specified in the code source, and should have permission to perform the set of operations represented in the permission collection object. Each class in the virtual machine may belong to one and only one protection domain, which is set by the class loader when the class is defined. However, not all class loaders have a specific protection domain associated with them: the class loader that loads the core Java API does not specify a protection domain. We can think of these core classes as belonging to the system protection domain. There are three utility methods of the ProtectionDomain class: public CodeSource getCodeSource Return the code source that was used to construct this protection domain. public PermissionCollection getPermissions Return the permission collection object that was used to construct this protection domain. 90