Configure static policy files in Java 2 security

By configuring the static policy files, the required permission will be granted for all of the Java programs.

Java 2 security uses several policy files to determine the granted permission for each Java program.

See the topic about Java 2 security policy files for the list of available policy files supported by WebSphere Application Server.

Two types of policy files are supported by WAS: dynamic policy files and static policy files. Static policy files provide the default permissions. Dynamic policy files provide application permissions.

Policy file name	Description
java.policy	Contains default permissions for all of the Java programs on the node. This file seldom changes.
server.policy	Contains default permissions for all of the WAS programs on the node. This file is rarely updated.
client.policy	Contains default permissions for all of the applets and client containers on the node.

The static policy file is not a configuration file managed by the repository and the file replication service. Changes to this file are local and do not get replicated to the other machine.

Tasks

1. Identify the policy file to update.

   • If the permission is required only by an application, update the dynamic policy file. Refer to Configure Java 2 security policy files.

   • If the permission is required only by applets and client containers, update the client.policy file. Refer to client.policy file permissions.

   • If the permission is required only by WAS (servers, agents, managers and application servers), update the server.policy file. Refer to server.policy file permissions.

   • If the permission is required by all of the Java programs running on the JVM, update the java.policy file. Refer to java.policy file permissions.

2. Stop and restart WAS.

The required permission is granted for all of the Java programs that run with the restarted JVM.

Example

If Java programs on a node require permissions, the policy file needs updating. If the Java program that required the permission is not part of an enterprise application, update the static policy file. The missing permission results in the creation of the java.security.AccessControlException exception. The missing permission is listed in the exception data.

For example:

java.security.AccessControlException: access denied (java.io.FilePermission 
C:/WAS_HOME/lib/mail-impl.jar read)

(iSeries) For example:

java.security.AccessControlException: access denied (java.io.FilePermission 
app_server_root/lib/mail-impl.jar read)

When a Java program receives this exception and adding this permission is justified, add a permission to an adequate policy file.

For example:

grant codeBase "file:user_client_installed_location" {
  permission java.io.FilePermission 
  "C:/WAS_HOME/lib/mail-impl.jar", 
  "read";
};

(iSeries) For example:

grant codeBase "file:user_client_installed_location" {
  permission java.io.FilePermission 
  "app_server_root/Base/lib/mail-impl.jar", 
  "read";
};

To decide whether to add a permission, refer to Access control exception for Java 2 security.

Subtopics

• java.policy file permissions
  Java 2 security uses several policy files to determine the granted permission for each Java program.
• server.policy file permissions
  Java 2 security uses several policy files to determine the granted permission for each Java program.
• client.policy file permissions
  Java 2 security uses several policy files to determine the granted permission for each Java program.

Related:

Java 2 security

Access control exception for Java 2 security

Protecting system resources and APIs (Java 2 security) for developing applications

Use PolicyTool to edit policy files for Java 2 security

Java 2 security policy files