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

ToolLocationNodeProperty - JEP-200 issue when configuring tools from Groovy scripts

    Details

    • Similar Issues:

      Description

      I have just update Jenkins from v2.89.4 to v.2.107.1

      I have a startup script to configure Jenkins's dumb Slaves.

      I'm geting the following error: 

      Caused by: java.lang.UnsupportedOperationException: Refusing to marshal ToolLocationNodeProperty$ToolLocation1_groovyProxy for security reasons; see https://jenkins.io/redirect/class-filter/

        Attachments

          Activity

          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Allan BURDAJEWICZ

          > Or does it also impact instantiation through traditional API (creating a node with the tool property from the UI) ?

          It should not. Keep in mind that Groovy script invocation impacts the in-memory model, and most likely you will not be able to reconfigure the tool properties from Web UI until the bogus property gets removed by restart or a manual edit

          Show
          oleg_nenashev Oleg Nenashev added a comment - Allan BURDAJEWICZ > Or does it also impact instantiation through traditional API (creating a node with the tool property from the UI) ? It should not. Keep in mind that Groovy script invocation impacts the in-memory model, and most likely you will not be able to reconfigure the tool properties from Web UI until the bogus property gets removed by restart or a manual edit
          Hide
          allan_burdajewicz Allan BURDAJEWICZ added a comment -

          Oleg Nenashev And that could be caused by any groovy class being rejected by the ClassFilter ? I mean that any user that trigger that kind of rejection via a groovy script could potentially impact the entire instance ?
          I wonder if that could be prevented / detected with script security (whether I would see the groovyProxy type in the signature to approve)

          Show
          allan_burdajewicz Allan BURDAJEWICZ added a comment - Oleg Nenashev And that could be caused by any groovy class being rejected by the ClassFilter ? I mean that any user that trigger that kind of rejection via a groovy script could potentially impact the entire instance ? I wonder if that could be prevented / detected with script security (whether I would see the groovyProxy type in the signature to approve)
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Allan BURDAJEWICZ yes, it can be technically prevented in this case. Not by Script Security, but by another engine

          Show
          oleg_nenashev Oleg Nenashev added a comment - Allan BURDAJEWICZ yes, it can be technically prevented in this case. Not by Script Security, but by another engine
          Hide
          allan_burdajewicz Allan BURDAJEWICZ added a comment -

          I have noticed that in this specific scenario, resaving the ToolProperty through the UI (by resaving the node from the UI for example) fixes the "in-memory" issue.

          Oleg Nenashev I understand this is not a defect, that Jenkins correctly rejects the proxy class. But maybe we could create a bug about the fact that it corrupts the groovy "in-memory" model, what's you opinion on that matter ?

          Show
          allan_burdajewicz Allan BURDAJEWICZ added a comment - I have noticed that in this specific scenario, resaving the ToolProperty through the UI (by resaving the node from the UI for example) fixes the "in-memory" issue. Oleg Nenashev I understand this is not a defect, that Jenkins correctly rejects the proxy class. But maybe we could create a bug about the fact that it corrupts the groovy "in-memory" model, what's you opinion on that matter ?
          Hide
          jglick Jesse Glick added a comment -

          It took me a while to understand what is being discussed here. In summary: a custom Groovy script sets an unserializable value to some Jenkins global configuration; and thereafter every attempt to save that top-level settings object (e.g., a GlobalConfiguration) reports an error. Indeed restarting Jenkins would correct the situation (because it would load from the last version of the settings that were correctly serialized); you could also fix this without a restart simply by setting a valid object. I do not think there is anything else to say here—using system Groovy scripts is tantamount to writing a custom plugin, and no particular level of safety is guaranteed.

          Show
          jglick Jesse Glick added a comment - It took me a while to understand what is being discussed here. In summary: a custom Groovy script sets an unserializable value to some Jenkins global configuration; and thereafter every attempt to save that top-level settings object (e.g., a GlobalConfiguration ) reports an error. Indeed restarting Jenkins would correct the situation (because it would load from the last version of the settings that were correctly serialized); you could also fix this without a restart simply by setting a valid object. I do not think there is anything else to say here—using system Groovy scripts is tantamount to writing a custom plugin, and no particular level of safety is guaranteed.

            People

            • Assignee:
              oleg_nenashev Oleg Nenashev
              Reporter:
              aamattos Andres Mattos
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: