velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <wgl...@forio.com>
Subject Re: Velocity Config/Security Issue
Date Sun, 15 Oct 2006 08:36:43 GMT
Hi Robin,

I set up a test server and duplicated this issue.  Here's the
specifics of what's going on with a suggested solution (long email).

By default, the Tomcat security manager policy prohibits reflection on
classes in the org.catalina hierarchy.  This prevents web apps from
instantiating internal classes and doing things it shouldn't be doing.

When you write a JSP page that calls <%= request.getSession().getId()
%>  this is literally compiled into a class.  Since the code is called
directly, it works fine.

As a contrast, when Velocity calls $request.session.id it uses
reflection.  Since the $request reference is actually implemented by
org.apache.catalina.connector.RequestFacade (in Tomcat 5.5) any method
calls using reflection throw a security exception.

There are two possible solutions.

(1) Your hosting provider should add the following to the security
policy.  Note it is very specific - just applies to the two velocity
jars.  You'll need to change the path to match your webapp.

grant codeBase "file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-1.4.jar"
{
	permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.catalina.connector";
       permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.catalina.session";
       permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.catalina.core";
};


grant codeBase "file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-tools-view-1.2.jar"
{
	permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.catalina.connector";
	permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.catalina.session";
       permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.catalina.core";
};

(2) You can create your own implementations of HttpServletRequest and
HttpSession that simply delegate to the app server versions.  Since
your classes are outside of the org.catalina hierarchy there will be
no reflection-related security issues.  Then add your new wrapper to
the context with the same name "request".

To sum up, this issue is due to the use of reflection by Velocity and
a strict security policy in Tomcat.  Either changing the security
policy or changing the target of the reflection would solve the
problem.

I'm going to post a JIRA issue to the Velocity Tools list suggesting
that the project add a wrapper for $request to eliminate this issue.

Best, WILL

On 10/13/06, Robin Mannering <robin_mannering75@hotmail.com> wrote:
> Hi Will,
>
> Originally, any request to the $request object were just being ignored (or
> were throwing security exceptions).  So the Velocity page just output
> $request into the HTML.
>
> He then granted permission on the below package uisng the security manager
> and the request object was then 'working' although it was putting out the
> incorrect values.  The exceptions in the log then disappeared.
>
> Then, he ran the application without the Security manager and the $request
> object had expected values for methods such $request.contextPath and
> $request.session.id and everything worked fine.
>
> I'm unfamiliar with Security Managers, shall I ask him to apply just this
> one? (This has no reference to Velocity classes does it?)
>
> java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.core
>
> As an extra, do you know of a hosting company that has established clients
> using Velocity?  I might do well to move somewhere with direct experience of
> hosting with velocity.
>
> Thanks for all your help
> Robin

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Mime
View raw message