Before you begin
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.policy
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.
Several
product-reserved symbols are defined to associate the permission lists to
a specific type of resources.
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 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,
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";
};
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 task
If 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.
Example
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:
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.