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