Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-49147

JEP-200 location-based whitelisting broken in obsolete versions of Tomcat

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • Jenkins 2.103 running on Debian 8 with OpenJDK 1.8.0_131 and Tomcat8

      I followed my normal procedure in updating our Jenkins builder:

      • Update all Jenkins plugins first.
      • Update jenkins core (using .war file)

      I got the error message about JEP-200 and XStream, so I browsed to the wiki page. It had a note in there about -Dhudson.remoting.ClassFilter=, with a comma-separated list of class names from the log file. I got the list of classes:

      # grep -ri rejecting /var/log/tomcat8/catalina.out | awk -F ' ' '{print $2}' | sort | uniq
      hudson.model.Cause$UserIdCause
      hudson.model.Hudson$CloudList
      hudson.model.MyViewsProperty
      hudson.model.PaneStatusProperties
      hudson.model.Queue$State
      hudson.model.UpdateSite
      hudson.model.View$PropertyList
      hudson.node_monitors.ArchitectureMonitor
      hudson.node_monitors.ClockMonitor
      hudson.node_monitors.DiskSpaceMonitor
      hudson.node_monitors.ResponseTimeMonitor
      hudson.node_monitors.SwapSpaceMonitor
      hudson.node_monitors.TemporarySpaceMonitor
      hudson.remoting.RemoteInvocationHandler$RPCRequest
      hudson.scm.SCMRevisionState$None
      hudson.search.UserSearchProperty
      hudson.slaves.JNLPLauncher
      hudson.slaves.RetentionStrategy$2
      hudson.tasks.LogRotator
      hudson.tasks.Shell$DescriptorImpl
      hudson.triggers.SCMTrigger$BuildAction
      hudson.triggers.SCMTrigger$DescriptorImpl
      hudson.triggers.SCMTrigger$SCMTriggerCause
      hudson.util.CopyOnWriteMap$Hash
      jenkins.model.BuildDiscarderProperty
      jenkins.model.ProjectNamingStrategy$DefaultProjectNamingStrategy
      jenkins.security.ApiTokenProperty
      jenkins.security.LastGrantedAuthoritiesProperty
      jenkins.slaves.RemotingWorkDirSettings
      

      So, I added those as a comma-separated list to -Dhudson.remoting.ClassFilter= and restarted Tomcat. Jenkins came back (authentication worked, but no build information is available, and slaves cannot connect), but I am now seeing a message about "You have data stored in an older format and/or unreadable data.". I am a bit afraid I will lose my build history and other metadata if I click on "Discard Unreadable Data". Is that a "safe" operation for my builds metadata?

      Also, why do I need to add so many exclusions to the hudson.remoting.ClassFilter, some of which seem to be internal to jenkins/hudson? Shouldn't that "just work"? Did I do something wrong in the upgrade?

          [JENKINS-49147] JEP-200 location-based whitelisting broken in obsolete versions of Tomcat

          Jesse Glick added a comment -

          no matter what Docker version of Tomcat8 I use, I cannot repro

          Odd. I will try to reproduce using a non-Docker-based installation, and/or using the Jessie image to install Tomcat from update sources. Again, if I can reproduce, the fix is probably straightforward and might help users of even more exotic containers.

          Is it safe to point Winstone at my existing /home/jenkins directory (with my config.xml and other metadata)? Will it pick up the previous settings from Tomcat8

          It should. Probably goes without saying, but—create a backup first.

          Jesse Glick added a comment - no matter what Docker version of Tomcat8 I use, I cannot repro Odd. I will try to reproduce using a non-Docker-based installation, and/or using the Jessie image to install Tomcat from update sources. Again, if I can reproduce, the fix is probably straightforward and might help users of even more exotic containers. Is it safe to point Winstone at my existing  /home/jenkins  directory (with my config.xml and other metadata)? Will it pick up the previous settings from Tomcat8 It should. Probably goes without saying, but—create a backup first.

          Jesse Glick added a comment -

          using the Jessie image to install Tomcat from update sources

          Finally able to reproduce it this way. Perhaps this was just a bug fixed in the 8.0.x line; 8.0.22, 8.0.38, and 8.0.40 mention potentially related fixes in the changelog. So I wonder why Jessie (even jessie-backports) is shipping a version obsolete since late 2014.

          Jesse Glick added a comment - using the Jessie image to install Tomcat from update sources Finally able to reproduce it this way. Perhaps this was just a bug fixed in the 8.0.x line; 8.0.22, 8.0.38, and 8.0.40 mention potentially related fixes in the changelog . So I wonder why Jessie (even jessie-backports ) is shipping a version obsolete since late 2014.

          Daniel Beck added a comment -

          LTS-candidating this in case 2.103ish becomes baseline.

          Daniel Beck added a comment - LTS-candidating this in case 2.103ish becomes baseline.

          Kyle Mott added a comment - - edited

          jglick, I migrated our deployment to native Winstone, and everything seems to have come back (slaves connected, jobs show up along with metadata, etc.).

          However, when I go to trigger a job, I am getting this now in the job log console:

          java.lang.ClassCastException: java.util.HashMap cannot be cast to hudson.scm.SCMRevisionState
          	at org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState.get(MultiSCMRevisionState.java:56)
          	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:110)
          	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85)
          	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75)
          	at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
          	at hudson.security.ACL.impersonate(ACL.java:274)
          	at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
          	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
          	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
          	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
          	at java.lang.Thread.run(Thread.java:748)
          Finished: FAILURE
          

          Is there some way to fix this?

          Kyle Mott added a comment - - edited jglick , I migrated our deployment to native Winstone, and everything seems to have come back (slaves connected, jobs show up along with metadata, etc.). However, when I go to trigger a job, I am getting this now in the job log console: java.lang.ClassCastException: java.util.HashMap cannot be cast to hudson.scm.SCMRevisionState at org.jenkinsci.plugins.workflow.steps.scm.MultiSCMRevisionState.get(MultiSCMRevisionState.java:56) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:110) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:274) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang. Thread .run( Thread .java:748) Finished: FAILURE Is there some way to fix this?

          Jesse Glick added a comment -

          kmott I have not seen that and it looks unrelated. Best to file separately with steps to reproduce, or send to the users’ list.

          Jesse Glick added a comment - kmott I have not seen that and it looks unrelated. Best to file separately with steps to reproduce, or send to the users’ list.

          Kyle Mott added a comment -

          If I trigger the build again, it goes away, so I'm guessing some transient turd left by Tomcat. Thanks again for all of the help Jesse!

          Kyle Mott added a comment - If I trigger the build again, it goes away, so I'm guessing some transient turd left by Tomcat. Thanks again for all of the help Jesse!

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/java/jenkins/security/ClassFilterImpl.java
          http://jenkins-ci.org/commit/jenkins/655be64a1753a3077a81fc0c34573bca74dcf5a0
          Log:
          JENKINS-49147 Tolerate unusual CodeSource.location format from old versions of Tomcat.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/java/jenkins/security/ClassFilterImpl.java http://jenkins-ci.org/commit/jenkins/655be64a1753a3077a81fc0c34573bca74dcf5a0 Log: JENKINS-49147 Tolerate unusual CodeSource.location format from old versions of Tomcat.

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/src/main/java/jenkins/security/ClassFilterImpl.java
          http://jenkins-ci.org/commit/jenkins/cd875f0e5aa8191e414a8b9940b02137d8ffb2f4
          Log:
          Merge pull request #3264 from jglick/Tomcat-JENKINS-49147

          JENKINS-49147 Tolerate unusual CodeSource.location format from old versions of Tomcat

          Compare: https://github.com/jenkinsci/jenkins/compare/dbc75125c565...cd875f0e5aa8

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/src/main/java/jenkins/security/ClassFilterImpl.java http://jenkins-ci.org/commit/jenkins/cd875f0e5aa8191e414a8b9940b02137d8ffb2f4 Log: Merge pull request #3264 from jglick/Tomcat- JENKINS-49147 JENKINS-49147 Tolerate unusual CodeSource.location format from old versions of Tomcat Compare: https://github.com/jenkinsci/jenkins/compare/dbc75125c565...cd875f0e5aa8

          Daniel Beck added a comment -

          Resolved towards 2.104.

          Daniel Beck added a comment - Resolved towards 2.104.

          Daniel Beck added a comment -

          This is in 2.104 so realistic LTS baselines will include this (and we're aiming for 2.107).

          Daniel Beck added a comment - This is in 2.104 so realistic LTS baselines will include this (and we're aiming for 2.107).

            jglick Jesse Glick
            kmott Kyle Mott
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: