Practically all examples of the setup programs for remote object activation start out by specifying a security policy file to be used by the activation daemon when launching a new VM for an activatable object. Assuming that an activatable object needs access to a system resource, is it always necessary to do so?
It is common for the setup programs for remote object activation to specify a security policy file explicitly to be used for the VM's that are activated by the rmid daemon when a request to that effect is received from a client. For illustration, all the on-line remote object activation tutorials have their activation setup programs begin with statements like
Properties props = new Properties(); props.put( "java.security.policy", "/home/rvl4/a/kak/RMI13.d/policy" ) ActivationGroupID agi = ActivationGroup.getSystem().registerGroup( new ActivationGroupDesc( props, null ) ); .... ....The first statement creates an empty properties list with no default values. The second statement adds to this list and tells the system about the location of the security policy file. The third statement then creates an identifier for an activation group using the augmented Properties object props for the first argument to the ActivationGroupDesc constructor. Recall that the activation daemon will be able to launch a new VM for each separate activation group identifier in a setup program.
Assuming that the activatable objects need access to system resources, this raises the question of whether it is always necessary to specify a security policy file for the spawned VM's in the activation setup program. Instead, could one directly inform the activation daemon rmid about a security policy to use and then have the daemon apply that security to all the activatable objects?
ActivationGroupID agi = ActivationGroup.getSystem().registerGroup( new ActivationGroupDesc( null, null ) );where the first argument to the ActivationGroupDesc constructor is now set to null. But now the activation daemon must be invoked with the "-C" option as in the following example:
rmid -C-Djava.security.policy=/home/rvl4/a/kak/RMI13.d/policyThe security policy thus specified is passed on to each VM spawned by the activation daemon. While simplifying the code a little bit, this approach implies that all the spawned VM's will be governed by the same security policy. If an application demands that the different VM's spawned by the activation daemon be governed by different security policies, one has no choice but to take recourse to the first approach.