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?

Avi Kak

No. The alternative consists of directly informing the activation daemon about the security policy to use for the activatable objects. Before showing how that is done, let's look at how a typical activation setup program begins.

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?

Yes, it is possible to inform the activation daemon directly about the security policy to use for all the activatable objects. To use this alternative approach, in your activation setup program you could delete entirely the first two statements shown above, and replace the third statement with

    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/policy 

The 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.
0 Comments  (click to add your comment)
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

About | Sitemap | Contact