Re: security audit

Ed, 

Thanks for your comments (below).  I'd be happy to write a note for the docs 
after a bit of discussion here.  

Re: the SecurityManager.  That was suggested earlier this spring on the dev 
list.  I've looked into it.  It's complex, and requires knowledge of the 
Velocity source code.  Essentially, you have to split the files that execute 
the methods on the Java classes into a separate JAR file, then designate that 
jar file as not have permission to call getClassLoader.  This requires that you 
(A) know what those Velocity classes are (B) understand how to work with the 
security manager, which is quite complex, and (C) have to modify the Velocity 
package every time there is a new release.

I think it would be much simpler if the Velocity core simply refused to call 
methods on these dangerous classes, which 95% of velocity apps never need.  (I 
can't think of any scenario why you'd want to access a ClassLoader, although 
Nathan makes a good case for accessing java.lang.Class in code generation 
templates).  The apps which need this functionality can disable the security 
restriction through a property.

WILL

>From Ed Yu:

Good point, may be we need a section in the docs mentioning about
potential security implications. BTW, I think the SecurityManager is
designed to have fine grained access control over classes and method
calls. If you are interested, look into it.


_______________________________________
Forio Business Simulations
Will Glass-Husain
wglass@xxxxxxxxx
www.forio.com