Configure app.policy files

 

+

Search Tips   |   Advanced Search

 

Before you begin

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

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:

Changes made in these files are replicated to other nodes in the Network Deployment cell.

In WebSphere Application Server, applications that manipulate threads must have the appropriate thread permissions specified in the was.policy or app.policy file. Without the thread permissions specified, the application cannot manipulate threads and WAS throws a java.security.AccessControlException. If an administrator adds thread permissions to the app.policy file, the permission change requires a restart of the WebSphere Application Server. An administrator must add the following code to a was.policy or app.policy file for an application to manipulate threads: 

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:

The JAAS principal keyword is supported in a JAAS policy file when it is specified by the JVM system property, java.security.auth.policy. We can statically set the authorization policy files in java.security.auth.policy 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.

 

Example

Symbol Meaning
file:${application} Permissions apply to all resources within the application
file:${jars} Permissions apply to all utility Java archive (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.

There are five embedded symbols provided to specify the path and name for java.io.FilePermission. These symbols enable flexible permission specifications. The absolute file path is fixed after the installation of the application.

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

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

The app.policy file supplied by WAS resides at...

install_root/profiles/profile/config/cells/cell/nodes/node/app.policy

...which contains the following default permissions... 

grant codeBase "file:${application}" {
  // The following are required by Java mail
  permission java.io.FilePermission "${was.install.root}${/}java${/}jre${/}lib${/}ext${/}mail.jar", "read";
  permission java.io.FilePermission "${was.install.root}${/}java${/}jre${/}lib${/}ext${/}activation.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, 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.net.SocketPermission "*", "connect";
 permission java.util.PropertyPermission "*", "read";
};

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 exception, java.security.AccessControlException. 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"; 
};

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

 

What to do next

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

 

See Also

Java 2 security policy files
Access control exception

 

Related Tasks

Migrate security configurations from previous releases
Configure server.policy files
Configure client.policy files
Configure filter.policy files
Configure java.policy files
Use PolicyTool to edit policy files