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

Computer.threadPoolForRemoting can be poisoned by bad code

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • 2.449, 2.440.3

      Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads contextClassLoader being set to hudson.PluginManager$UberClassLoader.
      In cases where the bug did not appear the contextClassloader was the WebAppClassLoader.

      This was surprising as the code in question did not set the context classloader and was running on the Computer.threadPoolForRemoting ThreadPool.

      This shows that the contextClassloader in a task submitted to this ThreadPool is not stable.

      It is expected that the state of a thread run in an executor from Jenkins core is in a deterministic state. 

      The threadpool should be tolerant of when ad by whom Threads are created as well as ensure state is clean/stable before running tasks.
      e..g - in a way similar to the Timer threads by using like the ContextResettingExecutorService

          [JENKINS-72796] Computer.threadPoolForRemoting can be poisoned by bad code

          James Nord created issue -
          James Nord made changes -
          Assignee New: James Nord [ teilo ]
          James Nord made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          James Nord made changes -
          Description Original: Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads `contextClassLoader` being set to `hudson.PluginManager$UberClassLoader`.
          In cases where the bug did not appear the contextClassloader was the `WebAppClassLoader`.

          This was surprising as the code in question did not set the context classloader and was running on the Computer.threadPoolForRemoting threadpool.

          This shows that someone has changed the contextClassloader in a task submitted to this threadpool but did not clean up.

           

          Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks.
          e..g - in a way similar to the `Timer` threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java]
          New: Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads {{contextClassLoader}} being set to {{{}hudson.PluginManager$UberClassLoader{}}}.
          In cases where the bug did not appear the {{contextClassloader}} was the {{{}WebAppClassLoader{}}}.

          This was surprising as the code in question did not set the context classloader and was running on the {{Computer.threadPoolForRemoting}} {{{}ThreadPool{}}}.

          This shows that someone has changed the {{contextClassloader }}in a task submitted to this {{ThreadPool}} but did not clean up.

           

          Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks.
          e..g - in a way similar to the `Timer` threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java]
          James Nord made changes -
          Description Original: Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads {{contextClassLoader}} being set to {{{}hudson.PluginManager$UberClassLoader{}}}.
          In cases where the bug did not appear the {{contextClassloader}} was the {{{}WebAppClassLoader{}}}.

          This was surprising as the code in question did not set the context classloader and was running on the {{Computer.threadPoolForRemoting}} {{{}ThreadPool{}}}.

          This shows that someone has changed the {{contextClassloader }}in a task submitted to this {{ThreadPool}} but did not clean up.

           

          Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks.
          e..g - in a way similar to the `Timer` threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java]
          New: Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads {{contextClassLoader}} being set to {{{}hudson.PluginManager$UberClassLoader{}}}.
          In cases where the bug did not appear the {{contextClassloader}} was the {{{}WebAppClassLoader{}}}.

          This was surprising as the code in question did not set the context classloader and was running on the {{Computer.threadPoolForRemoting}} {{{}ThreadPool{}}}.

          This shows that someone has changed the {{contextClassloader }}in a task submitted to this {{ThreadPool}} but did not clean up.

           

          Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks.
          e..g - in a way similar to the {{Timer}} threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java]
          James Nord made changes -
          Description Original: Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads {{contextClassLoader}} being set to {{{}hudson.PluginManager$UberClassLoader{}}}.
          In cases where the bug did not appear the {{contextClassloader}} was the {{{}WebAppClassLoader{}}}.

          This was surprising as the code in question did not set the context classloader and was running on the {{Computer.threadPoolForRemoting}} {{{}ThreadPool{}}}.

          This shows that someone has changed the {{contextClassloader }}in a task submitted to this {{ThreadPool}} but did not clean up.

           

          Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks.
          e..g - in a way similar to the {{Timer}} threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java]
          New: Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads {{contextClassLoader}} being set to {{{}hudson.PluginManager$UberClassLoader{}}}.
          In cases where the bug did not appear the {{contextClassloader}} was the {{{}WebAppClassLoader{}}}.

          This was surprising as the code in question did not set the context classloader and was running on the {{Computer.threadPoolForRemoting}} {{{}ThreadPool{}}}.

          This shows that someone has changed the {{contextClassloader}} in a task submitted to this {{ThreadPool}} but did not clean up.

           

          Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks.
          e..g - in a way similar to the {{Timer}} threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java]
          James Nord made changes -
          Resolution New: Cannot Reproduce [ 5 ]
          Status Original: In Progress [ 3 ] New: Closed [ 6 ]
          James Nord made changes -
          Resolution Original: Cannot Reproduce [ 5 ]
          Status Original: Closed [ 6 ] New: Reopened [ 4 ]
          Daniel Beck made changes -
          Summary Original: Computer.threadPoolForRemoting can be poisened by bad code New: Computer.threadPoolForRemoting can be poisoned by bad code
          James Nord made changes -
          Status Original: Reopened [ 4 ] New: In Progress [ 3 ]
          James Nord made changes -
          Description Original: Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads {{contextClassLoader}} being set to {{{}hudson.PluginManager$UberClassLoader{}}}.
          In cases where the bug did not appear the {{contextClassloader}} was the {{{}WebAppClassLoader{}}}.

          This was surprising as the code in question did not set the context classloader and was running on the {{Computer.threadPoolForRemoting}} {{{}ThreadPool{}}}.

          This shows that someone has changed the {{contextClassloader}} in a task submitted to this {{ThreadPool}} but did not clean up.

           

          Whilst this is a bug somewhere that needs to be fixed, the threadpool should be tolerant of this by ensuring the threads are in a deterministic state before running tasks.
          e..g - in a way similar to the {{Timer}} threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java]
          New: Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads {{contextClassLoader}} being set to {{hudson.PluginManager$UberClassLoader}}.
          In cases where the bug did not appear the {{contextClassloader}} was the {{WebAppClassLoader}}.

          This was surprising as the code in question did not set the context classloader and was running on the {{Computer.threadPoolForRemoting}} {{ThreadPool}}.

          This shows that the {{contextClassloader}} in a task submitted to this {{ThreadPool}} is not stable.

          It is expected that the state of a thread run in an executor from Jenkins core is in a deterministic state. 

          The threadpool should be tolerant of when ad by whom {{Threads}} are created as well as ensure state is clean/stable before running tasks.
          e..g - in a way similar to the {{Timer}} threads by using like the [ContextResettingExecutorService|https://github.com/jenkinsci/jenkins/blob/19f0140adef29e86d150faa056a22ceb011c8b03/core/src/main/java/jenkins/util/ContextResettingExecutorService.java]

            teilo James Nord
            teilo James Nord
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: