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

Script approvals require a reboot to take effect

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • script-security-plugin
    • None
    • Jenkins 2.89.2
      Script Security Plugin 1.39 and 1.41
      Pipeline build calling methods that are not whitelisted by default.

      TL;DR:  It appears that pressing the "Approve" button on the .../scriptApproval/ WebUI has no effect until after Jenkins has been restarted.

       

      Full story:

      I defined a pipeline build that contained the code:

          final snapshotPropertiesReader = new java.io.StringReader(snapshotPropertiesAsString)
          final snapshotProperties = new Properties()
          snapshotProperties.load(snapshotPropertiesReader)
          discoHostedSnapshotName = snapshotProperties.getProperty('productUnderTest.SNAPSHOT')

       

      First time I ran this pipeline code, I was using script security plugin version 1.39 and the pipeline code failed because "Scripts not permitted to use new java.util.Properties" (as one would expect).  So I approved that method using the UI at http://myjenkinsserver/scriptApproval/.

      However, the second time I ran it, despite having "approved" the code, the pipeline code failed with exactly the same error at the same point.  Taking a look at the UI at http://myjenkinsserver/scriptApproval/ , I saw that "new java.util.Properties" was in the "Signatures already approved" list, but was also listed as needing approval.  That shouldn't happen - a method can't be both "already approved" and in need of approval...

      Pressing the "approve" button (again) made no difference to the list of "Signatures already approved" but did make the "pending approval" entry go away ... until I re-ran the build when it came back again.

      Updating the plugin from 1.39 to 1.41 (and restarting Jenkins) initially appeared to fix the issue in that the build went on to the next line (where it's calling method java.util.Properties load java.io.Reader) ... but approving that had no effect on the build, only on the UI.

      ...until I restarted Jenkins, at which point I was able to progress to the next line (where it's calling method java.util.Properties getProperty java.lang.String).

       

      i.e. It appears that signature "approval" only takes effect after a Jenkins restart.

       

      At this point, I took screenshots - "scriptApprovalUI.png" shows that the method java.util.Properties getProperty java.lang.String is approved, but it also awaiting approval - the same method should never be in both places at once.  "buildFailure.png" and "console_output.txt" show the build that failed (despite getProperty(String) being approved) and "pipeline.groovy" shows a (somewhat redacted) version of the pipeline code.

        1. buildFailure.png
          buildFailure.png
          20 kB
        2. console_output.txt
          5 kB
        3. pipeline.groovy
          2 kB
        4. scriptApprovalUI.png
          scriptApprovalUI.png
          25 kB

          [JENKINS-49621] Script approvals require a reboot to take effect

          Andrew Bayer added a comment -

          Are you seeing this for any classes other than java.util.Properties? I have some vague memory of weirdness with that class in script-security before.

          Andrew Bayer added a comment - Are you seeing this for any classes other than java.util.Properties ? I have some vague memory of weirdness with that class in script-security before.

          Andrew Bayer added a comment -

          Hmm, I can't reproduce this with script-security 2.41...

          Andrew Bayer added a comment - Hmm, I can't reproduce this with script-security 2.41...

          pjdarton added a comment -

          I'm not seeing this for any other classes other than java.util.Properties, but this was the only class whose methods were being flagged up by my code.

          i.e. it was affecting 100% of all method signatures I saw ... but they were all to do with java.util.Properties.

           

          As mentioned above, the issue continued after upgrading from 2.39 to 2.41 ... which was the point where I started taking screenshots.  Could it be that 2.39 writes the configuration in a manner than upsets 2.41 causing the unwanted behavior to continue, but a "clean" 2.41 has no such problem?

          pjdarton added a comment - I'm not seeing this for any other classes other than java.util.Properties, but this was the only class whose methods were being flagged up by my code. i.e. it was affecting 100% of all method signatures I saw ... but they were all to do with java.util.Properties.   As mentioned above, the issue continued after upgrading from 2.39 to 2.41 ... which was the point where I started taking screenshots.  Could it be that 2.39 writes the configuration in a manner than upsets 2.41 causing the unwanted behavior to continue, but a "clean" 2.41 has no such problem?

          Andrew Bayer added a comment -

          As it turned out, my testbed was on 2.39, everything worked fine, I upgraded to 2.41, and everything worked fine. So that's just weeeeeeeird.

          Andrew Bayer added a comment - As it turned out, my testbed was on 2.39, everything worked fine, I upgraded to 2.41, and everything worked fine. So that's just weeeeeeeird.

          pjdarton added a comment -

          Hmm, yes, that is odd.

          OK, if it's not reproducible for you then you're going to struggle to "fix" it, so I'd suggest we call a halt here, otherwise you'll just be chasing shadows.
          If this issue hits me again and I can get a reproducible test case then I'll get back in touch.

          pjdarton added a comment - Hmm, yes, that is odd. OK, if it's not reproducible for you then you're going to struggle to "fix" it, so I'd suggest we call a halt here, otherwise you'll just be chasing shadows. If this issue hits me again and I can get a reproducible test case then I'll get back in touch.

            Unassigned Unassigned
            pjdarton pjdarton
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: