AccessControlException

The Java 2 Security behavior is specified by its security policy. The security policy is an access-control matrix that specifies which system resources that certain code bases can access and who must sign them. The Java 2 Security policy is declarative and is enforced by the java.security.AccessController.checkPermission() method.

The following code example is the algorithm for the java.security.AccessController.checkPermission() method where caller m invoked the java.security.AccessController.checkPermission() method. For the full algorithm, see the API documentation for Class AccessController

i = m;
while (i > 0) {
  if (caller i's domain does not have the permission)
    throw AccessControlException;
  else if (caller i is marked as privileged)
    return;
  i = i - 1;
};

The algorithm requires that all the classes (callers) on the call stack be granted the said permissions when a java.security.AccessController.checkPermission() is performed, or the request is denied (a java.security.AccessControlException is thrown). However, if the caller is marked as privileged and the class (caller) is granted the said permissions, the algorithm returns at that point and does not walk the entire call stack. Subsequent classes (callers) do not need to be granted the required permission.

A java.security.AccessControlException exception is thrown as a result of certain classes on the call stack missing the required permissions during a java.security.AccessController.checkPermission() method. The following are the two possible resolutions to the java.security.AccessControlException exception:

• If the application is calling an API that is protected by Java 2 Security, then grant the required permission to the application Java 2 Security policy.
• If the application does not directly call an API that is protected by Java 2 Security, but is third-party code that accesses protected resources, you have to option to grant the application additional privileges. However, if granting the additional permissions gives the application more access than it should have, then it is likely that the application is not properly marked as privileged.

Example call stack

This is an example of a call stack where an application code is using a third party API utility library to update the password. The following is only an example to illustrate the point. It is not the ultimate guide of where to mark the code as privileged. The decision as to where is the appropriate place to mark the code as privileged is application specific and is unique in every situation, requiring great depth of domain knowledge and security expertise to make the correct judgement. There are a number of well written publications and books on this topic, it is highly recommended that you reference these materials for more detailed information.

Use the PasswordUtil utility to change the password of a user. You type in the old password and the new password twice to ensure that the correct password is entered. If the old password matches the one stored in the password file, the new password is stored and updates the password file. Lets assume that none of the stack frame is marked as privileged. According to the java.security.AccessController.checkPermission() algorithm, the application fails unless all the classes on the call stack are granted write permission to the password file. The client application should not be granted the permission to write to the password file directly and update the password file at will.

However, if the PasswordUtil.updatePasswordFile() method marks the code that accesses the password file as privileged, then the check permission algorithm does not check for the required permission from classes that call the PasswordUtil.updatePasswordFile() method for the required permission as long as the PasswordUtil class is granted the permission. Then the client application can successfully update a password without granting the permission to write to the password file.

The ability to mark code privileged is very flexible and powerful, yet it is a double edged sword. If this ability is not used correctly, the overall security of the system can be compromised and security holes will be exposed. The ability to mark code privileged must be used with extreme care.

Note: Domain knowledge and security expertise is required to decide where to mark the code as privileged. A security exposure can result from code that is incorrectly marked.

Resolution to java.security.AccessControlException

As described previously, there are two possibilities to resolve a java.security.AccessControlException exception. Judge these case by case to decide which of the following is the best resolution to the problem:

• Grant the missing permission to the application.
• Mark some code as privileged (keeping in mind concerns and risk of doing so).