On Mar 30, 2012, at 4:33 PM, Greg Trasuk wrote: > > 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.
The jar: class loader implementation, used to not work for nested jar references. I did some testing to see how much work it would take to make it work, and was able to make a few changes to the jar: handler to get recursive jar to work by using "lastIndexOf" instead of "firstIndexOf" when looking for the '/' in the path. I saw a change in JDK6 that made this change too, but I have not gone back to revisit this issue. A classloader that knows more about the specific needs of this environment is probably a better choice any way. > 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 think you meant explicit in one of these, didn't you? > 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. I have a project on java.net called "gosie" that is a serviceUI client environment which uses a modified version of the logic in the service starter mechanism. All I do, is rely on a list of host names and a list of URL suffixes (jar file paths) to construct a list of URLS which I then use a DynamicPolicy to grant AllPermission with. I really feel that this is the right thing to do, because I then use PAM based authentication and authorization through my authlib project on java.net to make sure that users can only use the appropriate functions of the service. Gregg Wonderly
