Configuring the was.policy file for Java 2 security
If the application has specific resources to access, update the was.policy file.
Before you begin
profile_root/config/cells/cell_name/applications/
ear_file_name/deployments/application_name/META-INF/was.policy
See Java 2 security policy files for the list of available policy files that are supported by WebSphere Application Server Version 6.1.
The union of the permissions that
are contained in the following files is applied to the WebSphere Application Server enterprise application:
- Any policy file that is 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 cell.
Symbol | Definition |
---|---|
file:${application} | Permissions apply to all resources used 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 within the application |
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 WebSphere Application Server
creates a java.security.AccessControlException exception. If you add the permissions to the
was.policy file for a specific application, you do not need to restart 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";
};
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.
Other than these blocks, you can specify the module name for granular settings. For
example,
grant codeBase "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";
};
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 task
Tip: Syntax errors in the policy files cause the application
server to fail. Use care when editing these policy files.
Procedure
Results
Example
java.security.AccessControlException: access denied (java.io.FilePermission
${was.install.root}/java/ext/mail.jar read)
If 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:
Note: The following examples are split into several lines for
illustration only. You actually enter the permission on one line.
java.security.AccessControlException: access denied (java.io.FilePermission
${was.install.root}/java/ext/mail.jar read)
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
"${was.install.root}$(/)java$(/)jre$(/)lib$(/)ext$(/)mail.jar", "read";
};
To determine whether to add a permission, see Access control exception for Java 2 security.