How to analyze a Security Manager Issue


Java has the concept of Security Manager. You can read up on this here:, and for more detail: and

In simple terms, running under SecurityManager involves the following aspects:

Debugging a Security Issue

Typically an indication that you are dealing with a security manager issue is that you get an "access denied" error. There are three types of Security Manager issues you might encounter:

The first step to debugging a security manager issue is to determine which class library is at fault. First identify what java API call is being made. For this you need the stack trace from the Exception.

If the code is in a Derby user's application or in other third party software, you're done, just point them to the stack trace. If it's a Java class Library, you need to create a test case, with a program and a policy file and report to the vendor. If it's a Derby problem, you need to add a privileged block and/or adjust the policy files.

Example 1: Java Class Library

Step 1: Analyze the Stack Trace:

In this example the class throwing the security exception is "".

Step 2: Look at the java API javadoc

In the example above, this is:

Should this method throw a security exception? If not as in this case the problem is probably in the java class library.

Step 3: Create a stand-alone java reproduction to report to the vendor

Step 3.a. Create a small java program with the call.

If the problem is a java class library issue, try to make a stand alone java reproduction to report to the vendor. First make a small java program with the call. Analyzing the source code will help. For example:

Step 3.b. Create a policy file

Next make a policy file. In this case we don't need any special permissions, so the policy file does not have any. See for a description of the available permissions.

Step 3.c Run with Security Manager

Next run the program with security manager on.

Step 4: Report the problem to the vendor

Do this using your support channels.

Example 2: Derby Issue

The other kind of issue is one where we find the java class library is expected to throw a permission error, but Derby does not wrap the call in a privilege block. An example of such a case is DERBY-6349 where an intentional change to the java class library caused a test failure.

Step 1: Analyze the Stack Trace

The failure had the following stack trace:

Here again we identify the java API call. In this case TimeZone.setDefault(), called from TimeZoneTestSetup.

Step 2: Look at the java API javadoc

The Derby code in TimeZoneTestSetup was doing this:


where requestedDefault was a valid Timezone object passed in. The super class' method setDefault was called.

After checking with the jvm vendor, it seemed with a newer JVM version we now needed 'write' permission for this call. So we needed to

Step 3a. Wrap the offending call in a Privileged Block

Wrap the setDefault call in a privilege block, e.g.

Step 3.b. Add permissions to the Policy File

Make sure the correct permissions are in the policy file. In this case we needed:

AnalyzingSecurityManagerIssues (last edited 2013-11-08 05:10:12 by MyrnavanLunteren)