Design question on ClassLoading

[Greg Trasuk <tr...@stratuscom.com>]

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.
	

Re: Design question on ClassLoading

[Gregg Wonderly <ge...@cox.net>]

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