Java Reference
In-Depth Information
*/
Bank2 temp =
(Bank2)Naming.lookup("rmi://" + HOST
+ "/Account" + acctNum[i]);
//Now invoke the methods of the interface to
//display details of associated account…
System.out.println("\nAccount number: "
+ temp.getAcctNum());
System.out.println("Name: "
+ temp.getName());
System.out.println("Balance: "
+ temp.getBalance());
}
}
catch(ConnectException conEx)
{
System.out.println(
"Unable to connect to server!");
System.exit(1);
}
catch(Exception ex)
{
ex.printStackTrace();
System.exit(1);
}
}
}
Output for this client will be exactly as shown in Fig. 5.5 for Method 1 .
5.5
RMI Security
If both the client and server processes have direct access to the same class fi les, then
there is no need to take special security precautions, since no security holes can be
opened up by such an arrangement. However, an application receiving an object for
which it does not have the corresponding class fi le can try to load that class fi le from
a remote location and instantiate the object in its JVM. Unfortunately, an object passed
as an RMI argument from such a remote source can attempt to initiate execution on
the client's machine immediately upon deserialisation—without the user/programmer
doing anything with it! Such a security breach is not permitted to occur, of course. The
loading of this fi le is handled by an object of class SecureClassLoader , which must
have security restrictions defi ned for it. File java.policy defi nes these security restric-
tions, while fi le java.security defi nes the security properties. Implementation of the
security policy is controlled by an object of class RMISecurityManager (a subclass of
SecurityManager ). The RMISecurityManager creates the same 'sandbox' rules that
Search WWH ::




Custom Search