Page History

...

Compliant Solution

J2SE 1.2 added two methods — methods—checkPermission(Permission perm) and {{checkPermission(Permission perm, Object context) — to }}—to the SecurityManager class. The motivations for this change included:

• Eliminating the necessity to hardcode names of checks in method names.
• Encapsulating the complicated algorithms and code for examining the Java runtime in a single checkPermission() method.
• Supporting introduction of additional permissions by subclassing the Permission class.

The single argument checkPermission() method uses the context of the currently executing thread environment to perform the checks. If the context has the permissions defined in the local policy file, the check succeeds; otherwise, otherwise a SecurityException is thrown.

This compliant solution shows the single argument checkPermission() method and allows files in the local directory , with the dtd extension , to be read. DTDPermission is a custom permission that enforces this level of access. (See guideline SEC10-J. Define custom security permissions for fine grained security for details on creating custom permissions). Even if the java.io.FilePermission is granted to the application with the action "read", DTD files will be subject to additional access control.

...

Sometimes the security check code exists in one context (such as a worker thread) while the check has to be conducted on a different context, such as like another thread. The two argument checkPermission() method is used in this case. It accepts an AccessControlContext instance as the context argument. The effective permissions are not computed as the intersection of the permissions of the two contexts and consist of the permissions of the context argument only.

Both the single and double argument checkPermission() methods defer to the single argument java.security.AccessController.checkPermission(Permission perm) method. When invoked directly, this method operates only on the current execution context and, as a result, does not supersede the security manager's two argument version.

A cleaner approach to making a security check from a different context is to take a snapshot of the execution context in which the check must be performed, using the java.security.AccessController.getContext() method that returns an AccessControlContext object. The AccessControlContext class itself defines a checkPermission() method that encapsulates a context, instead of accepting the current executing context as a parameter. This allows the check to be performed at a later time, as shown belowin the following example.

// Take the snapshot of the required context, store in acc and pass it to another context
AccessControlContext acc = AccessController.getContext();

// Accept acc in another context and invoke checkPermission() on it
acc.checkPermission(perm);

...

Given knowledge of which operations are sensitive, as well as which security checks must be enforced for those operations, an automated tool could reasonably enforce the invariant that the sensitive operations are invoked only from contexts where the security checks have been performed.

...