Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-2608

Undertow Servlet 2.3.19 fails SecurityManager checks

XMLWordPrintable

      The WildFly CI job with the SecurityManager enabled fails when a WildFly Core with Undertow 2.3.19 integrated is tested.

      https://ci.wildfly.org/viewLog.html?buildId=518390&buildTypeId=WF_PullRequest_LinuxSmJdk17&fromSakuraUI=true

      The basic problem looks like this:

      Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.BootstrapMethodError: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.sun.misc")" in code source "(vfs:/content/with-default-ds-with-name-and-ctx.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.with-default-ds-with-name-and-ctx.war" from Service Module Loader") [in thread "default task-2"]
       at io.undertow.servlet@2.3.19.Final//io.undertow.servlet.spec.ServletPrintWriterDelegate.getUnsafe(ServletPrintWriterDelegate.java:252)
       at io.undertow.servlet@2.3.19.Final//io.undertow.servlet.spec.ServletPrintWriterDelegate.<clinit>(ServletPrintWriterDelegate.java:40)
       at io.undertow.servlet@2.3.19.Final//io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:385)
       at deployment.with-default-ds-with-name-and-ctx.war//org.jboss.as.test.integration.ee.naming.defaultbindings.datasource.DefaultDSWithCtxListenerServlet.doGet(DefaultDSWithCtxListenerServlet.java:38)
      

      I think it relates to this change: https://github.com/undertow-io/undertow/commit/e61f61cb23003a710869673f7ebc7ae20f575cc6#diff-c71808d66381caa12af3684[…]601734d681fe6a2a24f4L254-R252

      I don't know exactly why, but I figure the VM handles the mechanics of an anonymous inner class differently from a method reference

      Undertow 2.3.19 is now in WildFly Core 30.0.0.Beta1, but we can't upgrade full WildFly to that because it will break CI.

              bstansbe@redhat.com Brian Stansberry
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: