[ http://issues.apache.org/jira/browse/VELTOOLS-66?page=all ]
Nathan Bubna updated VELTOOLS-66:
---------------------------------
Issue Type: New Feature (was: Bug)
No, I don't think this is our bug in the least.
We're talking about public methods that implement a very public and standard
interface. Reflection is a longstanding and fully legitimate way to access
such an API in java and should not be treated as a second class citizen here.
Further, this appears to be a problem introduced with Tomcat 5.5. If anyone
needs to create such a secure wrapper, it is them. It is not Velocity nor
VelocityTools' job to maintain an implementation or wrappers for the servlet
API.
I'll leave this open as a feature request and will be happy to consider patches
toward providing access to key servlet functions in a way that doesn't offend
Tomcat's security policy, but i'll be honest and say that it'll take a lot of
convincing to get me to implement (or accept patches that do) this only to get
around Tomcat's shortcoming. There needs to be some other, better motive for
me.
Of course, the wiki is wide open for such things. :)
> 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/[email protected]/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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
