Bug 64488

The ImportHandler code should not be made privileged.

You need to grant the necessary permissions to whatever code calls ImportHandler.

In a default Tomcat installation, the necessary permission should be granted in the catalina.policy file.

It is possible, but unlikely, that a privileged block is missing elsewhere. If you can provide the simplest possible JSP that triggers this issue on a clean Tomcat 10 install we can take a look.

(In reply to volosied+apache from comment #0)
> Permission: 
> ("java.io.FilePermission"
> "/Library/Java/JavaVirtualMachines/adoptopenjdk-8-openj9.jdk/Contents/Home/
> jre/lib/rt.jar" "read")

How does it happen that it does not have a read permission for "rt.jar"?

In your case (looking at the proposed patch - attachment 37286 [details]) it is a getResource() call that is blocked by lacking permissions. Does it mean that not only loading of resources, but loading classes from rt.jar is blocked as well? Why? For what purpose? (*)

Is it a real-world configuration? Why is it configured like that?


(*) E.g. looking a 'loadClass(name)' call a few lines later just below the code affected by the patch - at ImportHandler line 463. - Will it fail?


(In reply to Mark Thomas from comment #1)
> If you can provide the simplest possible JSP that triggers this issue on a
> clean Tomcat 10 install we can take a look.

+1

I would like to see steps and code that are sufficient to reproduce the behaviour.

(From your stack trace I guess that you are running a JSP page, but not from within Apache Tomcat.)

(In reply to volosied+apache from comment #0)

A pair of minor comments regarding the patch

> +  @Override
> +  public Boolean run() {
> +      return cl.getResource(path) == null;
> +  }

The code fragment above uses autoboxing. The code style in Tomcat is to use explicit boxing.

(Configuration of compiler warnings for Eclipse IDE is documented in /res/ide-support/eclipse/java-compiler-errors-warnings.txt)

> From:

If that was not intended, you may want to configure user.email setting in your clone of the repository.

Hello,

Thank you so much for the quick replies. I looked more into my issue, and I have a better idea of what’s occurring.  I do not believe anything is wrong with the ImportHandler after all. 

In my  Open Liberty build, I had a development security property enabled,  unknown to me,  that logs AccessControl exceptions and allows the application to continue.  When I removed that property, I encountered a different error: jakarta.el.ELException: Function [:Boolean] not found. This may relate to the the fact that rt.jar contains the Boolean class (which EL doesn't have access to?).

I tested the same JSP on Tomcat (with security enabled), and encountered the very same exception. 

This is the troublesome EL Expression: “${Boolean(true)}” 

I tested it in Tomcat 7 and 9, and the same exception is thrown. The behavior is consistent everywhere.  However, can anyone explain it is that way (or point me to any resources)? My current understanding is that, when security is enabled, EL(or Tomcat?) doesn’t have access, by default, to the java runtime jar, rt.jar? (Which may explain why the original error asked me add the java.io.FilePermission to the rt.jar)  Although I tried modifying the permissions in Tomcat but was unsuccessful in getting the EL code to run with security enabled.  

However, I tested further, and the following code does work?  I’m assuming because it’s not going through EL? 

    <%
        Boolean b = new Boolean("true");
        System.out.println("Boolean Result: " + b);
    %>

    <%= b %>

I’m not very familiar with java security and, this is beyond what I originally started looking into, but, once again, thank you for your help. And I'll mark this issue as resolved/invalid. 

Full Exception: 

javax.el.ELException: Function [:Boolean] not found
    org.apache.el.parser.AstFunction.getValue(AstFunction.java:148)
    org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:190)
    org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:701)
    org.apache.jsp.el_jsp._jspService(el_jsp.java:163)
    org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:71)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
    org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:477)
    org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
    org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
    sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source)
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    java.lang.reflect.Method.invoke(Method.java:498)
    org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282)
    org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279)
    java.security.AccessController.doPrivileged(AccessController.java:770)
    javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
    org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314)
    org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170)
    java.security.AccessController.doPrivileged(AccessController.java:734)
    org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
    sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    java.lang.reflect.Method.invoke(Method.java:498)
    org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282)
    org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279)
    java.security.AccessController.doPrivileged(AccessController.java:770)
    javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
    org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314)
    org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:253)

At first glance, I'd expect that to work. Re-opening while I dig into what is going on...

Thanks for the test case. It makes debugging what is going on a lot easier.

I think there is a bug here.
 
Over time we have added various optimisations to the ImportHandler to address performance issues caused by the ambiguity introduced in EL 3.0. A good summary of those ambiguities and the associated performance issues can be found in https://tomcat.markmail.org/thread/pcxxg4ql6mxjwcmd and the links in the first email of that thread.

One of those optimisations was to do a resource lookup before trying to load the class as this was considerably quicker for the "not a class" case and only marginally slower for the "is a class" case. It is this resource lookup that is failing due to a lack of read permission.

Given that this test is there to optimise the "not a class" case, that the return value is thrown away and that the class loading happens a few lines later, I think your proposed patch is along the right lines. We've been moving towards removing anonymous classes so I am going to try a variation of your patch that uses an inner class.

Fixed in:
- master for 10.0.0-M6 onwards
- 9.0.x for 9.0.36 onwards
- 8.5.x for 8.5.56 onwards

Tomcat 7 doesn't support EL 3.0