Browse DevX
Sign up for e-mail newsletters from DevX


Check java.policy at Build Time to Avoid Runtime Errors

Don't wait until runtime to discover that there's a syntax error in java.policy. Use a simple utility to check java.policy at build time to avoid unexpected runtime failures.

he changes to Java's security implementation have made it more robust and introduced more programmatic hooks for developers to add to Java's default security mechanisms. Oddly, even with the introduction of Java Authentication and Authorization Services (JAAS) and its subsequent inclusion in the core API as of JDK 1.4, Java security still relies on a structured text format for its core configuration files: java.security and java.policy. While it is well known that there is a certain amount of overhead to parse XML files, the idiosyncratic layout of a security "grant block" in java.policy means that there are no standard tools to effectively verify its syntactic correctness at build time.

If your security needs are minor, your policy file simple, and your team is small, then it is unlikely that you view this as a serious shortcoming. However, if your environment and security needs are complex, and your team is fairly large then there is ample opportunity to inadvertently introduce syntactic errors into the java.policy file that won't be recognized until runtime. While extending the Policy class to be backed by an XML file is an option, frequently Sun's default implementation is what is relied upon and this leaves open the possibility of runtime issues arising with the java.policy file.

To remedy this situation, I coded a simple utility to check java.policy and let me know whether it is syntactically correct. The utility also prints out the specified permissions for each codebase of interest. This article will walk you through the code (download it here or from the link in the left-hand column) and discuss the utility's function as well as some of the basics of Java 2 security.

What You Need
Java 1.3 or later version. 1.3 has reached its "end of life" according to Sun so I recommend downloading at least 1.4x if you can.

As you read this article it will be helpful to have your java.policy and java.security files available. These two essential Java configuration files are located by default in the ${JAVA_HOME}/jre/lib/security directory. The security.policy file's role with respect to permissions is that it allows you to specify the policy files that are to be consulted by your application. The permissions in the file URLs that are specified are cumulative, meaning that they are aggregated at runtime to create the full list of permissions allocated to your application(s). The two URLs noted by default are listed below and while there is some benefit to adhering to standard locations for your policy file there is nothing that prevents you from changing it.

A replacement location can be specified with the VM argument:

Also note that while you can use the policy.url mechanism to specify multiple policy files you only need one and you can name it whatever you'd like.

The security.policy file is structured like a standard Java properties file, which makes it easier to manage and is less likely to change than java.policy. You'll see too that many of the settings pertain to cryptography providers, the keystore, and the like. These aren't the kinds of things that multiple developers are likely to modify.

One other setting in security.policy that is critical to the programmatic access to java.policy is the policy provider setting. This is the class that the audit utility must instantiate first to assemble the permissions for evaluation.

The code below is the typical way to get at the Policy file object.

pcoll = Policy.getPolicy().getPermissions(cs);
This call obtains the Policy file object and then the PermissionsCollection associated with it. More on this in a bit.

Thanks for your registration, follow us on our social networks to keep up-to-date