Java Reference
In-Depth Information
the source code you write, but indirectly by some method that your code calls.
In practice, the best way to determine the needed permissions is often to run the
code without any policy file and see what runtime exceptions are thrown. Then
adjust the policy file to add the indicated permissions and run again.
To get started and to be sure that all other requirements are met and that the
code is working nominally, one could use a wide open policy - i.e. grant all
permissions to everything. The policy file to grant all permissions reads
grant
{
permission java.security.AllPermission;
}
;
Obviously, using such a policy file in a production environment is, well, bad
policy. But using this policy file during testing is a good way to get both client
and server running quickly. The above lines can be created with a text editor and
saved in a file named, say,
grantall.policy
. Then, add the following to the
launch line when launching both the server and the client:
-Djava.security.policy
=
grantall.policy
As discussed in Chapter 14, it is probably easiest to use the SDK
policytool
to create and edit policy files. That tool has a graphical user interface with intel-
ligent pull-down menus that restrict the choices to ones that make sense for the
task at hand, thereby reducing errors by minimizing the need to fully understand
the policy file syntax. Still, policy files are just text files, and this makes it easy
to display policy file snippets here.
Once we are convinced that everything else is working correctly, this permis-
sive policy file should be replaced with a more restrictive one. For the server, we
create a file called
local-server.policy
containing these lines:
grant
{
permission java.net.SocketPermission
"
localhost
"
,
"
accept,connect,resolve
"
;
}
;
Later we create another policy file for use with a remote server.
For the client, when running on the same host as the server, the permission
required is also a network socket permission, but only for the
connect
and
resolve
actions. The client also needs a
java.io.FilePermission
in order to read
the location specified by the server's
“
file:
„
codebase.
To summarize, when running the client and server on the same machine,
we arrange for the client to use a local
CLASSPATH
that does not include the
remote stub classes. That means the client must look in the server's codebase
for the downloadable class files. That codebase specification is received from
the RMI registry. Since we're using the same machine, that codebase will be a
Search WWH ::
Custom Search