Permissions Outside of Policy Files

The appletviewer installs a security manager programatically; it cannot be disabled. It will use the standard policy files; to use additional policy files, specify the appropriate policy argument with the −J argument: piccolo appletviewer −J−Djava.security.policy=URL Although it obeys the default rules for accessing classes in packages via the accessClassInPackage permission discussed earlier, the appletviewer also allows you to restrict or allow access to classes in the sun package through a special property file. That property is set in the appletviewer properties menu. The Java Plug−in The Java Plug−in installs a security manager programatically; it cannot be disabled. It will use the standard policy files; to use additional policy files, you must use the Java Plug−in Control Panel. On the advanced tab of that panel, you can specify the desired java.security.policy argument. The Java Plug−in supports an alternate sandbox. This sandbox is used whenever the Plug−in runs an applet that has been signed. When the Plug−in encounters a signed jar file, it will present a dialog box to the user. The user has the option of giving the signed code permission to perform any operation for this session only or anytime it runs code signed by the given organization. Otherwise, the code will run with normal permissions based on its codebase and the permissions in the relevant policy files. This is the model used by Netscape 6 as well since Netscape 6 uses the Java Plug−in for all applets. Other Java−enabled browsers Older versions of Netscape and all versions of Internet Explorer define their own sandbox. Those sandboxes are completely unrelated to the policy−based model weve discussed here. They provide the same restrictions that we have discussed in this chapter applets cannot read files, can only open sockets back to the host from which they were loaded, have limited property permissions, and no other permissions; its simply that you cannot modify the sandbox administratively. These browsers do allow code to be signed, in which case the user can optionally grant the code permission to perform many operations. In addition, they allow developers to ask for particular operations to be performed using proprietary APIs. Check with the browser vendor for more details.

2.6.1 The Default Policy File

One way or another, the three common Java environments will use the same policy files to determine the parameters of the sandbox. By default, users do not have a .java.policy file in their home directory, which means that the default set of permissions for all Java programs running in the sandbox is defined by the JREHOMElibsecurityjava.policy file. Here are the contents of that file in 1.3: Installed extensions are granted all permissions grant codeBase file:{java.home}libext { permission java.security.AllPermission; }; All code is allowed the following permissions grant { Anyone can call Thread.stop , though only for