The access checking algorithm has been described as computing an
intersection of the sets of permissions of all the
ProtectionDomains on the call stack. One way of
computing this intersection would have been the eager way: A running
variable is maintained to keep track of the intersection set for the
frames on the stack at any particular instant. As soon as a new frame is
put on the stack, the variable is updated by the runtime by intersecting
the permissions set for this latest
ProtectionDomain with the old value of the
variable. The downside of eager access checking is obvious: if in that
control flow sequence no call is ever made to the security manager, then
the entire effort will have been in vain. Because permission checking
usually happens less frequently than cross-
ProtectionDomain calls on an average, eager
evaluation can be expected to be inefficient.
The second way to compute this intersection is the lazy way
previously described: The intersection is computed with respect to the
call stack only at the instant the permission check is requested.
As regards its practical implementation, the "computation of the
intersection of permission sets" is not implemented as a set
operation. Instead, an equivalent approach is followed: Starting from
the newest frame on the call stack and moving towards the oldest, the
implies() method is called on the
ProtectionDomain corresponding to each class on the
call stack. If the
implies() method returns
false at any stage, an
AccessControlException is thrown; otherwise the
next stack frame in sequence is considered. The correspondence between
this approach and the set intersection mechanism described earlier
should be clear.
Internally, a call to the
implies() method
leads to the
ProtectionDomain going back to
the
Policy object and asking for the
refreshed security policy (recall that dynamic policy refresh is allowed
from the Java 2 platform SDK 1.4 onwards only). The
ProtectionDomain then calls the
implies() method on the (refreshed) policy object
thus returned and passes itself along with the permission to be checked
to this method. Inside the
implies() method of
the
Policy object, the up-to-date
Permissions set corresponding to the
ProtectionDomain specified is obtained from its
cache (or re-read from the source, if not yet available in the cache,
and subsequently put into the cache) and the called
implies() method. As a result,
the
implies() method is called on the
PermissionCollection object contained therein that
matches the type of the permission to be checked. As previously
discussed, the
PermissionCollection will
return
true if the requested permission matches or is implied by
any of the individual permissions contained within it.
Return to
article.
| 
