WAS v8.5 > Reference > Configuration file descriptions

server.policy file permissions

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

See Java 2 security policy files for the list of available policy files that are supported by WebSphere Application Server.

The server.policy file is a default policy file that is shared by all of the WASs on a node. The server.policy file is not a configuration file that is managed by the repository and the file replication service. Changes to this file are local and do not replicate to the other machine.

If the default permissions for a server (the union of the permissions defined in the java.policy file and the server.policy file) are enough, no action is required. The default server policy is picked up automatically. If a specific change is required to some of the server programs on a node, update the server.policy file with the Policy Tool. Refer to the Use PolicyTool to edit policy files for Java 2 security topic to edit policy files. Changes to the server.policy file are local for the node. Syntax errors in the policy files cause the application server to fail. Edit these policy files carefully. An updated server.policy file is applied to all the server programs on the local node. Restart the servers for the updates to take effect.

To add permissions to an application, use the app.policy file and the was.policy file.

Updates to the app.policy file only apply to the enterprise applications on the node to which the app.policy file belongs.

When we do need to modify the server.policy file, locate this file at: profile_root/properties/server.policy. This file contains these default permissions:

// Allow to use sun tools grant codeBase "file:${java.home}/../lib/tools.jar" {
  permission java.security.AllPermission;};

// WebSphere system classes grant codeBase "file:${was.install.root}/plugins/-" {
  permission java.security.AllPermission;};
grant codeBase "file:${was.install.root}/lib/-" {
  permission java.security.AllPermission;};
grant codeBase "file:${was.install.root}/classes/-" {
  permission java.security.AllPermission;};

// Allow the WebSphere deploy tool all permissions grant codeBase "file:${was.install.root}/deploytool/-" {
  permission java.security.AllPermission;};

// Allow Channel Framework classes all permission grant codeBase "file:${was.install.root}/installedChannels/-" {
  permission java.security.AllPermission;};

// WebSphere optional runtime classes grant codeBase "file:${was.install.root}/optionalLibraries/-" {
  permission java.security.AllPermission;};

If some server programs on a node require permissions that are not defined as defaults in the server.policy file and the server.policy file, update the server.policy file. The missing permission creates the java.security.AccessControlException exception. 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-impl.jar read)

The previous two 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 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"; };

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

Restart all of the Java processes for the updated server.policy file to take effect.

Related concepts:

Access control exception for Java 2 security

Related

Configure static policy files in Java 2 security
Migrate, coexist, and interoperate – Security considerations
Use PolicyTool to edit policy files for Java 2 security

Reference:

Java 2 security policy files
app.policy file permissions
client.policy file permissions
filter.policy file permissions
java.policy file permissions

+

Search Tips   |   Advanced Search