"Unable to start the server: Error starting server : access denied" after upgrading the Gateway

Products

• STARTER PACK-7
• CA Rapid App Security
• CA API Gateway

Issue/Introduction

Upgrades to the Gateway application (via?Layer7_vX.Y.Z.L7P) make many changes to the files located on the appliance that control the Gateway application. In certain circumstances, the Gateway application may fail to start after an upgrade with the following example error(s):

Could not load Logmanager "com.l7tech.server.boot.GatewayBoot$GatewayLogManager"
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "setContextClassLoader")
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "setIO")
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "null/ssglog.properties" "read")
**** Unable to start the server: Error starting server : access denied ("java.io.FilePermission" "null/ssglog.properties" "read")

The Gateway utilizes certain Java specific implementations in order to control what files on the file system are accessible by certain parts of the Gateway application. This control is implemented outside of the normal file permissions used in a Linux environment. The Gateway controls this behavior with a particular file. This file is regularly updated as a matter of course during the application patching process. It is possible that the patching process did not complete successfully and will result in the Gateway not starting properly.

 

Environment

Release:
Component: APIGTW

Resolution

Troubleshooting and Resolution

The Gateway application should be executed with certain command-line options that enforce certain Java-specific security controls. When these security controls are not configured properly then the above errors may be presented in the Gateway log upon initialization. You can check to see if these security settings are present by doing the following:

1. Log into the Gateway appliance as the?ssgconfig user.
2. Select Option #2:?Use a privileged shell (root).
3. Check the running Java processes

ps awwx | grep ssg.policy

4. You should see output similar to the following:

/opt/SecureSpan/JDK/bin/java -Dcom.l7tech.server.home=/opt/SecureSpan/Gateway/node/default -Djava.ext.dirs=/opt/SecureSpan/JDK/jre/lib/ext:/opt/SecureSpan/Gateway/runtime/lib/ext -server -Djava.net.preferIPv4Stack=false -Djava.security.policy=/opt/SecureSpan/Gateway/runtime/etc/ssg.policy

If the above output is visible--specifically that java.security.policy?is set to /opt/SecureSpan/Gateway/runtime/etc/ssg.policy--then the Gateway's internal security controls are correctly configured and that is not the issue. If that output is visible then please open a new support request with Layer 7 Support at CA Technologies.?If the above output does not occur then the Gateway needs to be inspected for consistency in certain configuration files. We can check if the Gateway appliance is built properly using the following command:

grep ssg.policy /opt/SecureSpan/Gateway/runtime/etc/profile.d/ssgruntimedefs.sh

This command should return the following output:

default_java_opts="$default_java_opts -Djava.security.policy=${SSG_HOME}/runtime/etc/ssg.policy"

If this entry is not present then it needs to be added to?ssgruntimedefs.sh?at line #13. After making the change, restart the Gateway service and check to see if it starts properly. If it starts properly, the Gateway is repaired. If it does not start properly then please open a new support request with Layer 7 Support at CA Technologies