hai
i found the answer
*******************************
Security
One of the most common problems one encounters with RMI is a failure due to security constraints. This section gives a very brief introduction to the Java security model as it relates to RMI. For a more complete treatment, one should read the documentation for the Java SecurityManager and Policy classes and their related classes. Note that this section assumes that one is using Java 1.2 or later. Some of the statements are not true for earlier versions.
A Java program may specify a security manager that determines its security policy. A program will not have any security manager unless one is specified. One sets the security policy by constructing a SecurityManager object and calling the setSecurityManager method of the System class. Certain operations require that there be a security manager. For example, RMI will download a Serializable class from another machine only if there is a security manager and the security manager permits the downloading of the class from that machine. The RMISecurityManager class defines an example of a security manager that normally permits such downloads.
However, many Java installations have instituted security policies that are more restrictive than the default. There are good reasons for instituting such policies, and one should not override them carelessly. The rest of this section discusses some ways that can be used for overriding security policies that prevent RMI from functioning properly.
The SecurityManager class has a large number of methods whose name begins with check. For example, checkConnect (String host, int port). If a check method returns, then the permission was granted. For example, if a call to checkConnect returns normally, then the current security policy allows the program to establish a socket connection to the server socket at the specified host and port. If the current security policy does not allow one to connect to this host and port, then the call throws an exception. This usually causes your program to terminate with a message such as:
java.security.AccessControlException: access denied
(java.net.SocketPermission 127.0.0.1:1099 connect,resolve)
The message above would occur when an RMI server or client was not allowed to connect to the RMI registry running on the same machine as the server or client.
As discussed above, one sets the security policy by passing an object of type SecurityManager to the setSecurityManager method of the System class. There are several ways to modify the security policy of a program. The simplest technique is to define a subclass of SecurityManager and to call System.setSecurityManager on an object of this subclass. In the definition of this subclass,
you should override those check methods for which you want a different policy. For example, if you find that your "Hello, World!" program refuses to connect to the registry, then you should override the checkConnect methods. There are two checkConnect methods. The first was discussed above, and the second checkConnect method has a third parameter that specifies the security context of the request.
The following code illustrates how to do this:
System.setSecurityManager (new RMISecurityManager() {
public void checkConnect (String host, int port) {}
public void checkConnect (String host, int port, Object context) {}
});
The code above uses an anonymous inner class. Such a class is convenient when the class will only be used to construct an object in one place, as in this example. Of course, one could also define the subclass of RMISecurityManager in the usual way.
Defining and installing a security manager was the original technique for specifying a security policy in Java. Unfortunately, it is very difficult to design such a class so that it does not leave any security holes. For this reason, a new technique was introduced in Java 1.2, which is backward compatible with the old technique. In the default security manager, all check methods (except checkPermission) are implemented by calling the checkPermission method. The type of permission being checked is specified by the parameter of type Permission passed to the checkPermission method. For example, the checkConnect method calls checkPermission with a SocketPermission object. The default implementation of checkPermission is to call the checkPermission method of the AccessController class. This method checks whether the specified permission is implied by a list of granted permissions. The Permissions class is used for maintaining lists of granted permissions and for checking whether a particular permission has been granted.
This is the mechanism whereby the security manager checks permissions, but it does not explain how one specifies or changes the security policy. For this purpose there is yet another class, named Policy. Like SecurityManager, each program has a current security policy that can be obtained by calling Policy.getPolicy(), and one can set the current security policy using Policy.setPolicy, if one has permission to do so. The security policy is typically specified by a policy configuration file (or "policy file" for short) which is read when the program starts and any time that a request is made to refresh the security policy. The policy file defines the permissions contained in a Policy object. It is not inaccurate to think of the policy file a kind of serialization of a Policy object (except that a policy file is intended to be readable by humans as well as by machines). As an example, the following will grant all permissions of any kind to code residing in the RMI directory on the C: drive:
grant codeBase "file:C:/RMI/-" {
permission java.security.AllPermission;
};
The default security manager uses a policy that is defined in a collection of policy files. For the locations of these files see the documentation of the policytool program. If one wishes to grant additional permissions, then one can specify them in a policy file and then request that they be loaded using options such as the following:
java -Djava.security.manager -Djava.security.policy=policy-file MyClass
Both of the "-D" options specify system properties. The first system property has the same effect as executing the following statement as the first statement in your program:
System.setSecurityManager (new SecurityManager());
The second system property above causes the specified policy-file (which is specified with a URL) to be added to the other policy files when defining the entire security policy. The policytool can be used to construct the policy file, but one can also use any text editor.
As if this wasn't already complicated enough, there is yet another way to deal with the problem of downloading Serializable classes. The command-line option -Djava.rmi.server.codebase=code-base specifies a location from which Serializable classes may be downloaded. Of course, your security manager must recognize this system property, and not all of them will do so. Furthermore, as mentioned earlier, this is only necessary if you actually need to download Serializable classes.
