You should update the was.policy file if the application has specific resources to access.
Java 2 security uses several policy files to determine the granted permission for each Java program. The was.policy file is an application-specific policy file for WebSphere Application Server enterprise applications. This file is embedded in the META-INF/was.policy enterprise archive (.EAR)
file. The was.policy file is located in:
profile_root/config/cells/cell_name/applications/ ear_file_name/deployments/application_name/META-INF/was.policyThe union of the permissions that are contained in the following files is applied to the WebSphere Application Server enterprise application:
Changes made in these files are replicated to other nodes in the cell. Several product-reserved symbols are defined to associate the permission lists to a specific type of resources.
Symbol | Definition |
---|---|
file:${application} | file:${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 within the application |
grant codeBase "file:${application}" { permission java.lang.RuntimePermission "stopThread"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; };An administrator can add the thread permissions to the app.policy file, but the permission change requires a restart of WebSphere Application Server.
Important: The Signed By and the Java Authentication and Authorization Service (JAAS) principal keywords are not supported in the was.policy file. The Signed By keyword is supported in the java.policy, server.policy, and client.policy policy file. The JAAS principal keyword is supported in a JAAS policy file when it is specified by the java.security.auth.policy Java virtual machine (JVM) system property. You can statically set the authorization policy files in the java.security.auth.policy file with the auth.policy.url.n=URL, where URL is the location of the authorization policy. Other than these blocks, you can specify the module name for granular settings. For example,
"file:DefaultWebApplication.war" { permission java.security.SecurityPermission "printIdentity"; }; grant codeBase "file:IncCMP11.jar" { permission java.io.FilePermission "${user.install.root}${/}bin${/}DefaultDB${/}-", "read,write,delete"; };Five embedded symbols are provided to specify the path and name for the java.io.FilePermission permission. These symbols enable flexible permission specification. The absolute file path is fixed after the application is installed.
Symbol | Definition |
---|---|
${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 |
About this taskIf the default permissions for the enterprise application are enough, an action is not required. The default permissions are a union of the permissions that are defined in the java.policy file, the server.policy file, and the app.policy file. If an application has specific resources to access, update the was.policy file. The first two steps assume that you are creating a new policy file.
Tip: Syntax errors in the policy files cause the application server to fail. Use care when editing these policy files.
For more information, see Adding the was.policy file to applications . The following instructions describe how to import a was.policy file.
ExampleIf an application must access a specific resource that is not defined as a default in the java.policy file, the server.policy file, and the app.policy, delete the was.policy file for that application. The symptom of the missing permission is the java.security.AccessControlException exception. The missing permission is listed in the exception data:
java.security.AccessControlException: access denied (java.io.FilePermission
app_server_root/lib/mail-impl.jar read)
The previous example was split onto several lines for illustrative purposes only. When a Java program receives this exception and adding this permission is justified, add the following permission to the was.policy file:
grant codeBase "file:user_client_installed_location" { permission java.io.FilePermission "app_server_root/lib/mail-impl.jar", "read"; };
The previous example was split onto several lines for illustrative purposes only.
To determine whether to add a permission, see Access control exception .
Related reference
Java 2 security policy files
spi.policy file permissions
library.policy file permissions