library.policy file permissions

Java™ 2 security uses several policy files to determine the granted permission for each Java program.

For the list of available policy files that are supported by WebSphere® Application Server, see Java 2 security policy files.

The library.policy file is the template for shared libraries (Java library classes). Multiple enterprise applications can define and use shared libraries. Refer to Managing shared libraries for information on how to define and manage the shared libraries.

If the default permissions for a shared library (union of the permissions defined in the java.policy file, the app.policy file and the library.policy file) are enough, no action is required. The default library policy is picked up automatically. If a specific change is required to share a library in the cell, update the library.policy file.

Syntax errors in the policy files cause the application server to fail. Edit these policy files carefully.

Important: Do not place the codebase keyword or any other keyword after the grant keyword. The Signed By keyword and the Java Authentication and Authorization Service (JAAS) Principal keyword are not supported in the library.policy file. The Signed By keyword is supported in the java.policy, the server.policy, and the client.policy policy files. The JAAS Principal keyword is supported in a JAAS policy file when it is specified by the Java virtual machine (JVM) system property, java.security.auth.policy. You can statically set the authorization policy files in the java.security.auth.policy file with auth.policy.url.n=URL where URL is the location of the authorization policy.

To extract the policy file, use a command prompt to enter the following command using the appropriate variable values for your environment:The previous two lines were split onto two lines for illustrative purposes only.

[AIX Solaris HP-UX Linux Windows]

wsadmin> set obj [$AdminConfig extract cells/cell_name/nodes/
node_name/library.policy c:/temp/test/library.policy]

[IBM i]

wsadmin> set obj [$AdminConfig extract cells/cell_name/nodes/
node_name/library.policy /temp/test/library.policy]

[z/OS]

wsadmin> set obj [$AdminConfig extract cells/cell_name/nodes/
node_name/library.policy /temp/test/library.policy]

Edit the extracted library.policy file with the Policy Tool. For more information, see Using PolicyTool to edit policy files for Java 2 security.

To check in the policy file, use a command prompt to enter the following command using the appropriate variable values for your environment:An updated library.policy is applied to shared libraries after the servers restart.

[AIX Solaris HP-UX Linux Windows]

wsadmin> $AdminConfig checkin cells/cell_name/nodes/node_name/library.policy  
                c:/temp/test/library.policy $obj

[IBM i]wsadmin> $AdminConfig checkin cells/cell_name/nodes/node_name/library.policy  
                temp/test/library.policy $obj

[z/OS]

wsadmin> $AdminConfig checkin cells/cell_name/nodes/node_name/library.policy  
                 temp/test/library.policy $obj

Example

The union of the permission that is contained in the java.policy file, the app.policy file, and the library.policy file are applied to the shared libraries. The library.policy file is managed by configuration and file replication services.

Changes made in the file are replicated to other nodes in the cell.

[AIX Solaris HP-UX Linux Windows][z/OS]The library.policy file are supplied by WebSphere Application Server resides at: app_server_root/config/cells/cell_name/nodes/node_name/ directory. The file contains an empty permission entry as a default. For example:
grant {
  };
[IBM i]The library.policy file supplied by WebSphere Application Server resides in the profile_root/config/cells/cell_name/nodes/node_name/ directory. The file contains an empty permission entry as a default. For example:
grant {
  };

If the shared library in a cell requires permissions that are not defined as defaults in thejava.policy file, the app.policy file and the library.policy file, update the library.policy file. The missing permission causes the java.security.AccessControlException exception. The missing permission is listed in the exception data.

[Windows][AIX Solaris HP-UX Linux Windows]For example:
java.security.AccessControlException: access denied (java.io.FilePermission 
app_server_root/lib/mail-impl.jar read)
The previous lines are split into two lines for illustrative purposes only. The app_server_root variable represents your installation directory.
[IBM i]For example:
java.security.AccessControlException: access denied (java.io.FilePermission 
app_server_rootBase/lib/mail-impl.jar read)
The previous lines are split into two lines for illustrative purposes only.

When a Java program receives this exception and adding this permission is justified, add a permission to the library.policy file.

[Windows][AIX Solaris HP-UX Linux Windows]For example:
grant { permission java.io.FilePermission "app_server_root/lib/mail-impl.jar", "read"; };
The previous lines are split into two lines for illustrative purposes only. The app_server_root variable represents your installation directory.
[IBM i]For example:
grant codeBase "file:user_client_installed_location" { permission 
java.io.FilePermission "app_server_rootBase/lib/mail-impl.jar", "read"; };

The previous lines are split into two lines for illustrative purposes only

To decide whether to add a permission, refer to Access control exception for Java 2 security.

Restart the related Java processes for the changes in the library.policy file to become effective.