Steps to help resolve Java 2 Security problems
- Application throwing AccessControlException
A java.security.AccessControlException exception is thrown when not
all the classes on the call stack are granted the required permissions
during a java.security.AccessController.checkPermission(). The following
are the two possible resolutions to the
java.security.AccessControlException exception:
- If the application is calling a Java 2 Security protected API, then
grant the required permissions to the application Java 2 Security policy.
- If the application is NOT calling a Java 2 Security protected API
directly and the required permissions are not granted because of a
side-effect of the third party APIs accessing Java 2 Security protected
resources. If the application is granted the required permission, it gains
more access than it should. Then in this case, it is most likely that the
third party code that is accessing the Java 2 Security protected resource
is not properly marked as "privileged".
- Handling Applications That Are Not Java 2 Security
Ready
Debugging Aids
There are two primary aids, the WebSphere SystemOut.log file and the
com.ibm.websphere.java2secman.norethrow property.
The WebSphere SystemOut.log File
The AccessControl exception logged in the SystemOut.log will contain the
permission violation that caused the exception, the exception call stack,
and the permissions granted to each stack frame. This information is
usually enough to determine the missing permission and the code requiring
the permission.
The com.ibm.websphere.java2secman.norethrow Property
When Java 2 Security is enabled in WebSphere Application Server, the
Security Manager component will by default throw a
java.security.AccessControl exception when a permission violation occurs.
This exception, if not handled, will often cause a runtime failure. This
exception is also logged in the SystemOut.log.
However, when the JVM com.ibm.websphere.java2secman.norethrow property is
set and has a value of true, the Security Manager will not throw the
AccessControl exception -- it will only be logged.
Important: This property is intended for a sandbox or debug
environment only since it instructs the Security Manager not to throw the
AccessControl exception. By not re-throwing the exception, Java 2 security
is not actually enforced. This property should not be used in a production
environment where a relaxed Java 2 security environment will weaken the
very integrity Java 2 security is intended to produce.
This property is valuable in a sandbox or test environment where the
application can be thoroughly tested and the SystemOut.log can be
inspected for AccessControl exceptions. Since this property causes the
AccessControl exception not to be thrown, it will not be propagated up the
call stack and will not cause a failure. Without this property,
AccessControl exceptions would have to found and fixed one at a time.
- AccessController.doPrivileged()
Applications can add AccessControler.doPrivileged to their code to
avoid the access control exception. By adding the method, the caller tells
Java Runtime to ignore the status of its callers and that it is taking
responsibility in exercising its own permissions. The Sun web site has
enough information on this method. Please be warned, improperly
inserting a doPrivileged could open up security hole, so great
care and understanding of the implication of doPrivileged is required to
make a correct judgement whether a doPrivileged should be inserted or not.
1. Is Java 2 Security enabled?
- No - Are you initializing your own instance of a security
manager
- Yes - continue to the next question
2. Are SECJ0314W errors being thrown with both PMI and Java 2 security
enabled?
3. Are adapters failing on third party API calls when running with Java 2
security?
What to do next
If the preceding troubleshooting steps did not help solve your problem,
see the MustGather
for Java 2 Security problems to continue investigation. |