app.policy file permissions

Java 2 security uses several policy files to determine the granted permissions for each Java program. The union of the permissions contained in these following files is applied to the WebSphere Application Server enterprise application. This union determines the granted permissions.

The app.policy file is a default policy file shared by all of the WAS enterprise applications. The union of the permissions contained in the following files is applied to the WAS enterprise application:

• Any policy file specified in the policy.url.* properties in the java.security file.

• The app.policy files, which are managed by configuration and file replication services.

• The server.policy file.

• The java.policy file.

• The application was.policy file.

• The permission specification of the ra.xml file.

• The shared library, which is the library.policy file.

Changes made in these files are replicated to other nodes in the WAS ND cell.

Applications that manipulate threads must have the appropriate thread permissions specified in was.policy or app.policy. Without these permissions, applications cannot manipulate threads, and WAS throws java.security.AccessControlException exceptions. If an administrator adds thread permissions to the app.policy file, the permission change requires a restart of the WAS. To allow manipulation of threads for an application, add the following code to was.policy or app.policy...

grant codeBase "file:${application}" { 
  permission java.lang.RuntimePermission "stopThread"; 
  permission java.lang.RuntimePermission "modifyThread";
  permission java.lang.RuntimePermission "modifyThreadGroup"; 
}; 

Important: The Signed By and the JAAS principal keywords are not supported in the app.policy file. However, the Signed By keyword is supported in the following files: java.policy, server.policy, and the client.policy files. The JAAS principal keyword is supported in a JAAS policy file when it is specified by the java.security.auth.policy JVM system property. We can statically set the authorization policy files in the java.security.auth.policy property with auth.policy.url.n=URL where URL is the location of the authorization policy.

If the default permissions for enterprise applications (the union of the permissions defined in the java.policy file, the server.policy file and the app.policy file) are enough; no action is required. The default app.policy file is used automatically. If a specific change is required to all of the enterprise applications in the cell, update the app.policy file. Syntax errors in the policy files cause start failures in the application servers. Edit these policy files carefully.

Updates to the app.policy file only apply to the enterprise applications on the node to which the app.policy file belongs.

To extract the policy file...

wsadmin> set obj [$AdminConfig extract cells/cell/node/node/app.policy c:\temp\test\app.policy]

Use PolicyTool to edit the extracted app.policy file.

Changes to the app.policy file are local for the node.

To check in the policy file...

wsadmin> $AdminConfig checkin cells/cell/nodes/node/app.policy c:\temp\test\app.policy $obj

Symbols used to associate permission lists to a specific type of resource

Symbol	Meaning
file:${application}	Permissions apply to all resources within the application
file:${jars}	Permissions apply to all utility JAR files within the application
file:${ejbComponent}	Permissions apply to enterprise bean resources within the application
file:${webComponent}	Permissions apply to web resources within the application
file:${connectorComponent}	Permissions apply to connector resources both within the application and within stand-alone connector resources.

Symbols provided to specify the path and name for the java.io.FilePermission permission

Symbol	Meaning
${app.installed.path}	Path where the application is installed
${was.module.path}	Path where the module is installed
${current.cell.name}	Current cell name
${current.node.name}	Current node name
${current.server.name}	Current server name

Tip: We cannot use the ${was.module.path} in the ${application} entry.

(iSeries) (ZOS) The app.policy file supplied by WAS is located in the profile_root/config/cells/cell/nodes/node/app.policy, which contains the following default permissions:

In the following code sample, the first two lines related to java.io.FilePermission permission are split into two lines for illustrative purposes only.

grant codeBase "file:${application}" {
  // The following are required by JavaMail
  permission java.io.FilePermission "${was.install.root}${/}lib${/}activation-impl.jar", "read";
  permission java.io.FilePermission "${was.install.root}${/}lib${/}mail-impl.jar", "read";
};

grant codeBase "file:${jars}" {
  permission java.net.SocketPermission "*", "connect";
  permission java.util.PropertyPermission "*", "read";
};

grant codeBase "file:${connectorComponent}" {
  permission java.net.SocketPermission "*", "connect";
  permission java.util.PropertyPermission "*", "read";
};

grant codeBase "file:${webComponent}" {
  permission java.io.FilePermission "${was.module.path}", "read";
  permission java.io.FilePermission "${was.module.path}${/}-", "read, write"
  permission java.lang.RuntimePermission "loadLibrary.*";
  permission java.lang.RuntimePermission "queuePrintJob";
  permission java.net.SocketPermission "*", "connect";
  permission java.util.PropertyPermission "*", "read";
};
grant codeBase "file:${ejbComponent}" {
 permission java.lang.RuntimePermission "queuePrintJob";
 permission java.lang.RuntimePermission "loadLibrary.*";
 permission java.net.SocketPermission "*", "connect";
 permission java.util.PropertyPermission "*", "read";
 permission java.io.FilePermission "*", "read,write";
};

If all of the WAS enterprise applications in a cell require permissions that are not defined as defaults in the java.policy file, the server.policy file and the app.policy file, then update the app.policy file. The symptom of a missing permission is the java.security.AccessControlException exception.

Updates to the app.policy file only apply to the enterprise applications on the node to which the app.policy file belongs.

The missing permission is listed in the exception data, for example,

java.security.AccessControlException: access denied
(java.io.FilePermission
C:\WebSphere\AppServer\java\jre\lib\ext\mail.jar read)

When a Java program receives this exception and adding this permission is justified, add a permission to the server.policy file, for example:

grant codeBase "file:user_client_installed_location" {   
  permission java.io.FilePermission 
"C:\WebSphere\AppServer\java\jre\lib\ext\mail.jar", "read";
 };

The previous permission information lines are split for the illustration. You actually enter the permission on one line.

To decide whether to add a permission, refer to the AccessControlException topic.

Restart all WAS enterprise applications to ensure that the updated app.policy file takes effect.

Related:

Access control exception for Java 2 security

Configure Java 2 security policy files

Migrate, coexist, and interoperate - Security considerations

Use PolicyTool to edit policy files for Java 2 security

server.policy file permissions

client.policy file permissions

filter.policy file permissions

java.policy file permissions

Java 2 security policy files