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
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.
Table 1. Symbols defined to associate permission
lists to a specific type of resource. Several product-reserved
symbols are defined to associate the permission lists to a specific
type of resource.
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";
};
Table 2. Embedded symbols
provided to specify the path and name for the java.io.FilePermission
permission. 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
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: Examples that appear below 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.