The was.policy file

 

+

Search Tips   |   Advanced Search

 

 

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 WAS enterprise applications. It is embedded in the EAR file...

install_root/profiles/profile/config/cells/cell/applications/ear_file_name/deployments/appname/META-INF/was.policy

The union of the permissions contained in the following files is applied to the WAS 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 Network Deployment 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

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 WAS throws a java.security.AccessControlException. 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 app.policy, but the permission change requires a restart of the WebSphere Application Server.

The Signed By and the JAAS principal keywords are not supported in the was.policy file. The Signed By keyword is supported in the following policy files:

The JAAS principal keyword is supported in a JAAS policy file when it is specified by the JVM system property, java.security.auth.policy. We can statically set the authorization policy files in java.security.auth.policy with...

auth.policy.url.n=URL

...where URL is the location of the authorization policy.

Other than these blocks, one 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";
};

There are five embedded symbols provided to specify the path and name for the java.io.FilePermission. 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

 

Overview

If the default permissions for the enterprise application (union of the permissions defined in the java.policy file, the server.policy file and app.policy) are enough, no action is required. 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.

Note: Syntax errors in the policy files cause the application server to fail. Use care when editing these policy files.

 

Procedure

  1. Create or edit a new was.policy file using the Policy Tool.

  2. Package the was.policy file into the EAR file...

    1. Import the EAR file into an assembly tool.

    2. Open the Project Navigator view.

    3. Expand the EAR file and click META-INF. You might find a was.policy file in the META-INF directory. If you want to delete the file, right-click the file name and select Delete.

    4. At the bottom of the Project Navigator view, click J2EE Hierarchy.

    5. Import the was.policy file by right-clicking the Modules directory within the deployment descriptor and clicking Import > Import > File system.

    6. Click Next.

    7. Enter the path name to the was.policy file in the From directory field or click Browse to locate the file.

    8. Verify that the path directory listed in the Into directory field lists the correct META-INF directory.

    9. Click Finish.

    10. To validate the EAR file, right-click the EAR file, which contains the Modules directory, and click Run Validation.

    11. To save the new EAR file, right-click the EAR file, and click Export > Export EAR file. If you do not save the revised EAR file, the EAR file will contain the new was.policy file. However, if the workspace becomes corrupted, you might lose the revised EAR file.

    12. To generate deployment code, right-click the EAR file and click Generate Deployment Code.

  3. Update an existing installed application, if one already exists.

    1. Modify the was.policy file with the Policy Tool.

The updated was.policy file is applied to the application after the application restarts.

 

Example java.policy, server.policy, app.policy, was.policy

java.security.AccessControlException, 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 was.policy file:

grant codeBase "file:<user client installed location>" { permission java.io.FilePermission "C:\WebSphere\AppServer\java\jre\lib\ext\mail.jar", "read"; };.

To determine whether to add a permission, refer to the article, Access control exception.

 

What to do next

Restart all applications for the updated app.policy file to take effect.

 

See Also

Access control exception
Java 2 security policy files

 

Related Tasks

Migrating security configurations from previous releases
Configuring spi.policy files
Configuring library.policy files
Adding the was.policy file to applications
Import enterprise applications