Java 2 security uses several policy
files to determine the granted permissions for each Java program.
The union of the permissions that are contained in these following
files is applied to the WebSphere® Application Server enterprise
application. This union determines the granted permissions.
For the list of available policy files that are supported
by
WebSphere Application Server, see the
topic about Java 2 security policy files. The
app.policy file
is a default policy file that is shared by all of the
WebSphere Application Server enterprise applications.
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.
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 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 Java Authentication and Authorization
Service (JAAS) principal keywords are not supported in the app.policy file.
However, the Signed By keyword is supported in the following files: java.policy, server.policy,
and the client.policy files. 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 property
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
that is 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.
Note: Updates to the app.policy file
only apply to the enterprise applications on the node to which the app.policy file
belongs.
To extract the policy file, use a command prompt
to enter the following command on one line using the appropriate variable
values for your environment:
wsadmin> set obj [$AdminConfig extract cells/cell_name/node/node_name/app.policy c:\temp\test\app.policy]
Edit the extracted app.policy file
with the Policy Tool. For more information, see Using PolicyTool to edit policy files for Java 2 security. Changes to the app.policy file
are local for the node.
To check in the policy file, use a command
prompt to enter the following command on one line using the appropriate
variable values for your environment:
wsadmin> $AdminConfig checkin cells/cell_name/nodes/node_name/app.policy c:\temp\test\app.policy $obj
Table 1. Symbols used 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 |
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. |
Table 2. 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 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 |
Tip: You cannot use the ${was.module.path} in
the ${application} entry.
Attention: In the following code sample, the first two lines
that are related to java.io.FilePermission permission are split into
two lines for illustrative purposes only.
grant codeBase "file:${application}" {
// The following are required by JavaMail
permission java.io.FilePermission "${was.install.root}${/}lib${/}activation-impl.jar", "read";
permission java.io.FilePermission "${was.install.root}${/}lib${/}mail-impl.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
WebSphere Application Server 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
java.security.AccessControlException exception.
Note: Updates
to the app.policy file only apply to the enterprise applications
on the node to which the app.policy file belongs.
![[Windows]](../../windows.gif)
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";
};
The previous permission information lines are
split for the illustration. You actually enter the permission on one
line.
To decide whether to add a permission, refer to the AccessControlException
topic.
Restart all WebSphere Application Server enterprise applications
to ensure that the updated app.policy file takes
effect.