You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Will Glass-Husain (JIRA)" <ve...@apache.org> on 2006/10/16 06:16:35 UTC

[jira] Commented: (VELTOOLS-66) Velocity Tools gives access exception with $request reference under Tomcat security manager

    [ http://issues.apache.org/jira/browse/VELTOOLS-66?page=comments#action_12442456 ] 
            
Will Glass-Husain commented on VELTOOLS-66:
-------------------------------------------

Nathan, you make some good points.  

Though I'm not a Tools user, I don't mind making a patch for if you think it would be appropriate.  But I'll hold off for the moment.  Let me try posting an issue on the Tomcat site, see if there's any interest in handling this over there.  

If there does not seem to be progress at Tomcat I'd like to push again to just handle it on our side.  I've struggled with webapps on Tomcat with security policies -- undocumented permission needs (which are frequent in Tomcat and libraries) are very frustrating.    Velocity is confusing enough to new users without having an incomprehensible error that occurs in VelocityViewServlet but not JSP.  

Can we leave the issue open for the time being?



> Velocity Tools gives access exception with $request reference under Tomcat security manager
> -------------------------------------------------------------------------------------------
>
>                 Key: VELTOOLS-66
>                 URL: http://issues.apache.org/jira/browse/VELTOOLS-66
>             Project: VelocityTools
>          Issue Type: New Feature
>          Components: VelocityView
>    Affects Versions: 1.2
>            Reporter: Will Glass-Husain
>
> I'm labeling this as a bug, though it's arguable whether the fault is of Tomcat or Velocity.  Regardless, we should apply a workaround.  I've replicated this issue with Velocity 1.4 / Tools 1.2 / JDK 1.5 / Tomcat 5.5
> The problem.  When the Tomcat is run under the default security manager settings, it prohibits reflection on org.catalina classes.  This means that the reference $request.session.id fails with an access violation
> INFO:  Velocity  [error] PROGRAMMER ERROR : PropertyExector() : java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.connector)
> sometimes the package given is org.apache.catalina.core, somtimes org.apache.catalina.session, depending on various factors.
> Users can alter their security policy to allow this access.  But this is an obscure procedure and may not be feasible if you do not control your hosting environment.  For the record, the settings for catalina.policy are (change the path to suit 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";
> };
> As an alternative, I propose that the Velocity Tools project solve this by create a wrapper object for HttpServletRequest.  (presumably the problem also exists for $response, though I haven't tried it).  This object would simply pass through all calls to the server-provided HttpServletRequest. Obviously, there would need to be a parallel wrapper for HttpSession, HttpServletContext, and similar objects available from HttpServletRequest methods.  The result would be that the Velocity page would never apply reflection to a Catalina class.  (and hence never generate this security error).
> This issue is in reference to a problem encountered and described on the user list by Robin Mannering.
> http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg17060.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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