rmid(1)rmid(1)Namermid - The Java RMI Activation System Daemon
rmid starts the activation system daemon that allows objects to be
registered and activated in a virtual machine (VM).
SYNOPSISrmid [options]
DESCRIPTION
The rmid tool starts the activation system daemon. The activation sys‐
tem daemon must be started before activatable objects can be either
registered with the activation system or activated in a VM. See the
Java RMI Specification @
http://java.sun.com/javase/6/docs/platform/rmi/spec/rmiTOC.html and
Activation tutorials @
http://java.sun.com/javase/6/docs/technotes/guides/rmi/activation/over‐
view.html for details on how to write programs that use activatable
remote objects.
The daemon can be started by executing the rmid command, and specifying
a security policy file, as follows:
rmid -J-Djava.security.policy=rmid.policy
Note: When running Sun's implementation of rmid, by default you will
need to specify a security policy file so that rmid can verify whether
or not the information in each ActivationGroupDesc is allowed to be
used to launch a VM for an activation group. Specifically, the command
and options specified by the CommandEnvironment and any Properties
passed to an ActivationGroupDesc's constructor must now be explicitly
allowed in the security policy file for rmid. The value of the
sun.rmi.activation.execPolicy property dictates the policy that rmid
uses to determine whether or not the information in an Activation‐
GroupDesc may be used to launch a VM for an activation group.
Executing rmid by default
o starts the Activator and an internal registry on the default port,
1098, and
o binds an ActivationSystem to the name java.rmi.activation.Activa‐
tionSystem in this internal registry.
To specify an alternate port for the registry, you must specify the
-port option when starting up rmid. For example,
rmid -J-Djava.security.policy=rmid.policy -port 1099
starts the activation system daemon and a registry on the registry's
default port, 1099.
Starting rmid from inetd/xinetd
An alternative to starting rmid from the command line is to configure
inetd (Solaris) or xinetd (Linux) to start rmid on demand.
When rmid starts up, it attempts to obtain an inherited channel (inher‐
ited from inetd/xinetd) by invoking the System.inheritedChannel method.
If the inherited channel is null or not an instance of java.nio.chan‐
nels.ServerSocketChannel, then rmid assumes that it was not started by
inetd/xinetd, and it starts up as described above.
If the inherited channel is a ServerSocketChannel instance, then rmid
uses the java.net.ServerSocket obtained from the ServerSocketChannel as
the server socket that accepts requests for the remote objects it
exports, namely the registry in which the java.rmi.activation.Activa‐
tionSystem is bound and the java.rmi.activation.Activator remote
object. In this mode, rmid behaves the same as when it is started from
the command line, except:
o Output printed to System.err is redirected to a file. This file is
located in the directory specified by the java.io.tmpdir system
property (typically /var/tmp or /tmp) with the prefix "rmid-err"
and the suffix "tmp".
o The -port option is disallowed. If this option is specified, rmid
will exit with an error message.
o The -log option is required. If this option is not specified, rmid
will exit with an error message.
See the man pages for inetd (Solaris) or xinetd (Linux) for details on
how to configure services to be started on demand.
OPTIONS
-C<someCommandLineOption>
Specifies an option that is passed as a command-line argument to
each child process (activation group) of rmid when that process
is created. For example, you could pass a property to each vir‐
tual machine spawned by the activation system daemon:
rmid -C-Dsome.property=value
This ability to pass command-line arguments to child processes
can be useful for debugging. For example, the following command:
rmid -C-Djava.rmi.server.logCalls=true
will enable server-call logging in all child VMs.
-J<someCommandLineOption>
Specifies an option that is passed to the java interpreter run‐
ning rmid. For example, to specify that rmid use a policy file
named rmid.policy, the -J option can be used to define the
java.security.policy property on rmid's command line, for exam‐
ple:
rmid -J-Djava.security.policy=rmid.policy
-J-Dsun.rmi.activation.execPolicy=<policy>
Specifies the policy that rmid employs to check commands and com‐
mand-line options used to launch the VM in which an activation
group runs. Please note that this option exists only in Sun's
implementation of the Java RMI activation daemon. If this prop‐
erty is not specified on the command line, the result is the same
as if -J-Dsun.rmi.activation.execPolicy=default were specified.
The possible values of <policy> can be default, <policyClass‐
Name>, or none:
o default (or if this property is unspecified)
The default execPolicy allows rmid to execute commands with spe‐
cific command-line options only if rmid has been granted permis‐
sion to execute those commands and options in the security policy
file that rmid uses. Only the default activation group implemen‐
tation can be used with the default execution policy.
rmid launches a VM for an activation group using the information
in the group's registered activation group descriptor, an Activa‐
tionGroupDesc. The group descriptor specifies an optional Activa‐
tionGroupDesc.CommandEnvironment which includes the command to
execute to start the activation group as well as any command line
options to be added to the command line. By default, rmid uses
the java command found in java.home. The group descriptor also
contains properties overrides that are added to the command line
as options defined as:
-D<property>=<value>
The permission com.sun.rmi.rmid.ExecPermission is used to grant
rmid permission to execute a command, specified in the group
descriptor's CommandEnvironment to launch an activation group.
The permission com.sun.rmi.rmid.ExecOptionPermission is used to
allow rmid to use command-line options, specified as properties
overrides in the group descriptor or as options in the CommandEn‐
vironment, when launching the activation group.
When granting rmid permission to execute various commands and
options, the permissions ExecPermission and ExecOptionPermission
need to be granted universally (i.e., granted to all code
sources).
ExecPermission
The ExecPermission class represents permission for rmid to
execute a specific command to launch an activation group.
Syntax
The name of an ExecPermission is the path name of a command to
grant rmid permission to execute. A path name that ends in
"/*" indicates all the files contained in that directory
(where "/" is the file-separator character, File.separator‐
Char). A path name that ends with "/-" indicates all files and
subdirectories contained in that directory (recursively). A
path name consisting of the special token "<<ALL FILES>>"
matches any file.
Note: A path name consisting of a single "*" indicates all the
files in the current directory, while a path name consisting
of a single "-" indicates all the files in the current direc‐
tory and (recursively) all files and subdirectories contained
in the current directory.
ExecOptionPermission
The ExecOptionPermission class represents permission for
rmid to use a specific command-line option when launching
an activation group. The name of an ExecOptionPermission is
the value of a command line option.
Syntax
Options support a limited wildcard scheme. An asterisk signi‐
fies a wildcard match, and it may appear as the option name
itself (i.e., it matches any option), or an asterisk may
appear at the end of the option name only if the asterisk fol‐
lows either a "." or "=".
For example: "*" or "-Dfoo.*" or "-Da.b.c=*" is valid, "*foo"
or "-Da*b" or "ab*" is not.
Policy file for rmid
When granting rmid permission to execute various commands
and options, the permissions ExecPermission and ExecOption‐
Permission need to be granted universally (i.e., granted to
all code sources). It is safe to grant these permissions
universally because only rmid checks these permissions.
An example policy file that grants various execute permissions
to rmid is:
grant {
permission com.sun.rmi.rmid.ExecPermission
"/files/apps/java/jdk1.2.2/solaris/bin/java";
permission com.sun.rmi.rmid.ExecPermission
"/files/apps/java/jdk1.2.2/solaris/bin/java_g";
permission com.sun.rmi.rmid.ExecPermission
"/files/apps/rmidcmds/*";
permission com.sun.rmi.rmid.ExecOptionPermission
"-Djava.security.policy=/files/policies/group.policy";
permission com.sun.rmi.rmid.ExecOptionPermission
"-Djava.security.debug=*";
permission com.sun.rmi.rmid.ExecOptionPermission
"-Dsun.rmi.*";
};
The first two permissions granted allow rmid to execute the
1.2.2 version of the java and java_g commands, specified by
their explicit path names. Note that by default, the version
of the java command found in java.home is used (the same one
that rmid uses), and does not need to be specified in the pol‐
icy file. The third permission allows rmid to execute any com‐
mand in the directory /files/apps/rmidcmds.
The fourth permission granted, an ExecOptionPermission, allows
rmid to launch an activation group that defines the security
policy file to be /files/policies/group.policy. The next per‐
mission allows the java.security.debug property to be used by
an activation group. The last permission allows any property
in the sun.rmi property name hierarchy to be used by activa‐
tion groups.
To start rmid with a policy file, the java.security.policy
property needs to be specified on rmid's command line, for
example:
rmid -J-Djava.security.policy=rmid.policy
o
o <policyClassName>
If the default behavior is not flexible enough, an administrator
can provide, when starting rmid, the name of a class whose check‐
ExecCommand method is executed in order to check commands to be
executed by rmid.
The policyClassName specifies a public class with a public,
no-argument constructor and an implementation of the following
checkExecCommand method:
public void checkExecCommand(ActivationGroupDesc desc,
String[] command)
throws SecurityException;
Before launching an activation group, rmid calls the policy's
checkExecCommand method, passing it the activation group descrip‐
tor and an array containing the complete command to launch the
activation group. If the checkExecCommand throws a SecurityExcep‐
tion, rmid will not launch the activation group and an Activa‐
tionException will be thrown to the caller attempting to activate
the object.
o none
If the sun.rmi.activation.execPolicy property value is "none",
then rmid will not perform any validation of commands to launch
activation groups.
-log dir
Specifies the name of the directory the activation system daemon
uses to write its database and associated information. The log
directory defaults to creating a directory, log, in the directory
in which the rmid command was executed.
-port port
Specifies the port rmid's registry uses. The activation system
daemon binds the ActivationSystem, with the name java.rmi.activa‐
tion.ActivationSystem, in this registry. Thus, the ActivationSys‐
tem on the local machine can be obtained using the following Nam‐
ing.lookup method call:
import java.rmi.*;
import java.rmi.activation.*;
ActivationSystem system; system = (ActivationSystem)
Naming.lookup("//:port/java.rmi.activation.ActivationSystem");
-stop
Stops the current invocation of rmid, for a port specified by the
-port option. If no port is specified, it will stop the rmid run‐
ning on port 1098.
ENVIRONMENT VARIABLES
CLASSPATH
Used to provide the system a path to user-defined classes. Direc‐
tories are separated by colons. For example:
.:/usr/local/java/classes
SEE ALSOrmic(1), CLASSPATH @
http://java.sun.com/javase/6/docs/technotes/tools/index.html#classpath,
java(1)
20 Mar 2008 rmid(1)
