Hi all:
I'm working on the security and classloading systems for the Surrogate
container.
Background:
===========
The container hosts application modules. A surrogate is really a subset
of an application module, and I'm currently working on hosting modules
in the style that would traditionally be started with the ServiceStarter
mechanism. Specifically, I want the the standard infrastructure
services like Reggie, Outrigger, etc, to be hosted by the container (so
that a complete infrastructure can be deployed as one shot, and also to
allow users to deploy their own services in an uncomplicated way).
To package a service module for deployment, you create an archive file
and drop it into the container's 'deploy' directory. For example, my
Reggie module looks like:
reggie-module.ssar
|- lib
| |- reggie.jar
|- lib-dl
| |- reggie-dl.jar
|- reggie.config
|- start.properties
To facilitate this setup and avoid actually unpacking the archive file,
I wrote a classloader
(org.apache.river.container.classloading.VirtualFileSystemClassLoader)
that uses Apache commons-vfs to resolve class files inside the service
archive file.
So far, so good. Now when I've enabled security, the classloader gets
permission errors when it tries to resolve the ".class" files. That's
not a problem per se, since I haven't yet added the code to setup the
application module's code grants.
Question:
=========
My question is, would it be reasonable to make the
VirtualFileSystemClassLoader use privileged operations (the base policy
is to grant AllPermission to container code) to load classpath
resources, or should I make explicit "read" grants to the classpath
jars. In other words, does code implicitly have read access on its own
classpath, or should it be implicit. I'm leaning towards implicit
permission to load classes, mainly because I think it will be easier to
code, but I'm wondering if there are any counter-arguments.
Cheers,
Greg Trasuk.
