Java Reference
In-Depth Information
Call stack
Figure 14.1 The JVM
checks permissions by
collecting all protection
domains associated
with classes on the call
stack and seeing if each
involved protection do-
main has the specified
permission granted to it.
PermissionC
PermissionB
PermissionA
ProtectionDomain
Bundle A
A.class
B.class
C.class
PermissionD
PermissionB
PermissionA
ProtectionDomain
Bundle B
D.class
In this case, assume that class D performs a sensitive operation that triggers an internal
permission check using the AccessController.checkPermission(Permission p)
method. This checks whether at the point of the permission check, all protection
domains on the call stack have permission p . Looking at figure 14.1, the JVM performs
a stack walk from the class performing the security check and determines that classes
A , B , C , and D are involved. Subsequently, it determines that classes A and C originate
from the protection domain of Bundle B, and classes B and D originate from the pro-
tection domain of Bundle A. With this information, the JVM checks whether all pro-
tection domains have some permission implying the checked permission. If not, then
a security exception is thrown.
This provides a good foundation for understanding the Java security architecture,
but there's one final piece to the puzzle: privileged calls.
PRIVILEGED CALLS
You now know that checking a specific permission triggers a complete stack walk to col-
lect all involved protection domains and verify that they all imply that permission. This
is useful, but it's too restrictive by itself. For example, assume you have a service with a
method for appending a message to a log file. Because disk operations trigger file sys-
tem-related permission checks, all code on the call stack must have permission to write
to the file. This may be fine if only trusted code is involved; but in an extensible and col-
laborative environment like OSG i, you generally want to allow arbitrary bundles to
share code and services, so it's likely that some code on the call stack won't be trusted.
In such cases, if a permission check always walks up the entire call stack, you either
have to disallow all nontrusted code or grant code-sensitive permissions to untrusted
code. Neither choice is palatable, which is why Java supports privileged calls. A privi-
leged call is a mechanism to short-circuit the stack walk when performing a permission
check. In practice, this allows trusted code to perform sensitive operations on behalf
of code with insufficient permissions.
You achieve this by using the AccessController.doPrivileged() method, which
takes a PrivilegedAction instance (it has a run() method similar to a Runnable ).
When the doPrivileged() method is invoked, it invokes the run() method of the
passed-in PrivilegedAction . Any subsequent permission checks triggered by the
PrivilegedAction stop walking the call stack at the last privileged call. Thus, only the
protection domains from the privileged action onward are considered by subsequent
permission checks.
Search WWH ::




Custom Search