fact that Java applications have access to the entire Java VM, whereas Java applets do not. The
major difference with protection domains in Java 2 is the flexibility and control you have over how
security is implemented. Although complete coverage of Java security is beyond the scope of this
topic, we will give you a general idea how security works in Java as it relates to threads.
First we should mention that the SecurityManager class still exists in Java 2 and is also
backward compatible with previous versions of the JDK. The SecurityManager in Java 2 is
just a wrapper for compatibility where all security actions are forwarded on to the new protection
domain infrastructure. This means that you could continue to use the SecurityManager class in
a way that you may be familiar with, but its internal workings are far different. In fact, the
interface for security is the same for both the Thread and ThreadGroup classes, but the
implementation of security has changed.
The new security mechanism is based on the concept of having a set of permissions. A
Permission object in Java is really just an object that represents access to a protected resource.
All permissions in Java have a name as well as semantics that define access to a resource. You can
define your own permissions or you can use the predefined permissions in Java. For example, Java
has a SocketPermission object that can control access to networking resources. The
advantage of the Java 2 security mechanism is that a system administrator can define a set of
restrictions to place on Java programs. The administrator has fine-grained control of all actions
that can possibly be performed in the Java VM. Our focus is not on what all the permissions are or
how they are defined, but rather, that a set of permissions have been defined and that we must
adhere to these restrictions. For more information about Java security and permissions, see the Java
documentation or one of the topics recommended in Appendix B.
So how do permissions relate to threads? The simple answer is, "in three ways." Java 2 has
defined three permissions that all threads use. They are modifyThread, stopThread, and
modifyThreadGroup, all of which are defined in the RuntimePermission class. Each of
these permissions is used to protect Thread resources when certain methods are called.
The following lists the RuntimePermission target names that are used in conjunction with
Java threads:
·
modifyThread: This permission is accessed when a calling thread wants to access or
modify an unrelated thread in the Java VM.
·
stopThread: This permission is accessed when a calling thread wants to stop another
thread running in the Java VM.
·
modifyThreadGroup: This permission is accessed when a calling thread wants to
access or modify a ThreadGroup.
So how does all this work? When a thread resource needs protection, it can make a call into the
security mechanism to verify if the requested action should take place. If the security mechanism
does not object to the action, the call simply returns. If it does not permit the action, a security
exception is thrown. Let's take a look at a simple example (Code Example 10-2). The example
simply creates a new SecurityManager and then calls a few Thread and ThreadGroup
methods. If you execute this program from a command line, you should get a security exception.
We say "should" because if you have defined your security permissions to include the
"modifyThreadGroup" permission, the program will execute without a problem. Also, if you
remove the line that sets the SecurityManager, the program will also complete without any
errors.
Example 10-2 A Simple Security Exception
public class Simple {
static public void main(String s[]) {
Search WWH :
