• Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Major Major
    • script-security-plugin
    • None
    • 2.60.1

      We have rather complex build scripts in groovy to deal. After upgrade to 2.60.1 they start fail with:

      *14:18:45* ERROR: Build step failed with exception*14:18:45* org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: unclassified field java.io.File text*14:18:45* 	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.unclassifiedField(SandboxInterceptor.java:367)*14:18:45* 	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onSetProperty(SandboxInterceptor.java:217)*14:18:45* 	at org.kohsuke.groovy.sandbox.impl.Checker$5.call(Checker.java:297)*14:18:45* 	at org.kohsuke.groovy.sandbox.impl.Checker.checkedSetProperty(Checker.java:294)*14:18:45* 	at org.kohsuke.groovy.sandbox.impl.Checker$checkedSetProperty$2.callStatic(Unknown Source)*14:18:45* 	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)*14:18:45* 	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)*14:18:45* 	at Script1.run(Script1.groovy:11)*14:18:45* 	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.run(GroovySandbox.java:141)*14:18:45* 	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript.evaluate(SecureGroovyScript.java:165)*14:18:45* 	at hudson.plugins.groovy.SystemGroovy.run(SystemGroovy.java:95)*14:18:45* 	at hudson.plugins.groovy.SystemGroovy.perform(SystemGroovy.java:59)*14:18:45* 	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)*14:18:45* 	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:735)*14:18:45* 	at hudson.model.Build$BuildExecution.build(Build.java:206)*14:18:45* 	at hudson.model.Build$BuildExecution.doRun(Build.java:163)*14:18:45* 	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:490)*14:18:45* 	at hudson.model.Run.execute(Run.java:1735)*14:18:45* 	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)*14:18:45* 	at hudson.model.ResourceController.execute(ResourceController.java:97)*14:18:45* 	at hudson.model.Executor.run(Executor.java:405)*14:18:45* Build step 'Execute system Groovy script' marked build as failure
      

      Issues

      1. the 'field java.io.File text' was not offered in /scriptApproval
      2. after being added manually in xml it still failing with the same error (though i can see it in 'Signatures already approved')
      3. Permissive security plugin doesn't help

      So, we ended up with completely broken builds without any fallback options.

      Job Configuration
      Problematic step: Execute system Groovy script + Groovy script file
      Code:

      final File tmp = File.createTempFile(...)
      tmp.text = build.project.workspace.child('somefile').readToString()
      

       

          [JENKINS-45308] unclassified field java.io.File text

          Jesse Glick added a comment - - edited

          unclassified errors do not indicate that some signature is being rejected. They indicate that Jenkins cannot figure out what signature you were even trying to call. In this case you were trying to use this GDK method which for reasons TBD was not recognized. (Normally DefaultGroovyMethods is supported.) Possibly a dupe of one of the other bugs in this plugin.

          The workaround is the usual one: use actual methods defined in the Java Platform.

          (In this case you were trying to do local file operations, which are never going to be supported in sandbox mode since they are inherently security holes. You must use whole-script approval, or stop trying to use local files.)

          Jesse Glick added a comment - - edited unclassified errors do not indicate that some signature is being rejected. They indicate that Jenkins cannot figure out what signature you were even trying to call. In this case you were trying to use  this GDK method  which for reasons TBD was not recognized. (Normally DefaultGroovyMethods is supported.) Possibly a dupe of one of the other bugs in this plugin. The workaround is the usual one: use actual methods defined in the Java Platform. (In this case you were trying to do local file operations, which are never going to be supported in sandbox mode since they are inherently security holes. You must use whole-script approval, or stop trying to use local files.)

          Wojciech Duda added a comment -

          jglick can this approach be changed? I was trying to use a pretty convenient

          for(String fileName : bundleFileNames) {
              File k = new File(fileName)
              k.text = k.text.replaceAll("__cache_i18n_hash__", fullI18nHash)
          }
          

          to patch JavaScript files, but I get the same error. I had to switch to using sed on the command line to achieve the same. Or maybe I am just too inexperienced to understand what "actual methods defined in the Java Platform" means and how to achieve the same doing that? Can you point me to an example? Google searches have left me empty-handed.

          Wojciech Duda added a comment - jglick can this approach be changed? I was trying to use a pretty convenient for ( String fileName : bundleFileNames) { File k = new File(fileName) k.text = k.text.replaceAll( "__cache_i18n_hash__" , fullI18nHash) } to patch JavaScript files, but I get the same error. I had to switch to using sed on the command line to achieve the same. Or maybe I am just too inexperienced to understand what "actual methods defined in the Java Platform" means and how to achieve the same doing that? Can you point me to an example? Google searches have left me empty-handed.

          Jesse Glick added a comment -

          wduda please use the users’ list for help. JIRA is for reporting confirmed bugs and tracking their fixes.

          Jesse Glick added a comment - wduda please use the users’ list for help. JIRA is for reporting confirmed bugs and tracking their fixes.

          Denis Andreev added a comment -

          Hello everyone.

          Our team is constantly faced with the same difficulties when using ScriptApprovals.

          So, there are two possible solutions to avoid "unclassified" errors, am I right?:
          1)Modify methods that produce "unclassified" signatures
          2) Or fully disable script security plugin (in case declarative pipelines are used - https://issues.jenkins-ci.org/browse/JENKINS-53700)
          But what if any of the suggested methods are not applicable for our goals? Still we can't refuse using VCS for our pipelines.
          Is it possible to manually classified signature as not dangerous? Cause I have a big doubt that after running a build the newly appeared signature would match the one already approved due to different types "unclassified" vs "classified"?

          Denis Andreev added a comment - Hello everyone. Our team is constantly faced with the same difficulties when using ScriptApprovals. So, there are two possible solutions to avoid "unclassified" errors, am I right?: 1)Modify methods that produce "unclassified" signatures 2) Or fully disable script security plugin (in case declarative pipelines are used - https://issues.jenkins-ci.org/browse/JENKINS-53700 ) But what if any of the suggested methods are not applicable for our goals? Still we can't refuse using VCS for our pipelines. Is it possible to manually classified signature as not dangerous? Cause I have a big doubt that after running a build the newly appeared signature would match the one already approved due to different types "unclassified" vs "classified"?

          Jesse Glick added a comment -

          You cannot approve an “unclassified” signature because it has not been, well, classified. Errors about “unclassified” signatures represent bugs in the sandbox code. Please report them as distinct issues with complete, minimal steps to reproduce from scratch. Please use the users’ list for help or advice with other matters.

          Jesse Glick added a comment - You cannot approve an “unclassified” signature because it has not been, well, classified. Errors about “unclassified” signatures represent bugs in the sandbox code. Please report them as distinct issues with complete, minimal steps to reproduce from scratch. Please use the users’ list for help or advice with other matters.

          Denis Andreev added a comment - - edited

          Thank you jglick! Your answer have shed the light on my problem!
          To reproduce the error follow steps:
          1) Create pipeline job
          2) Definition -> pipeline script -> fill script with below code

          import groovy.json.*
          
          def jsonSlurper = new JsonSlurper()
          def json = jsonSlurper.parseText('[{"text":"STATUS"},{"text":"BRIEF_DESCRIPTION"}]')
          
          echo json.text.toString() // With checkbox checked on "groovy sandbox" will cause 'unclassified' error
          echo json['text'].toString() // Will not cause the error in any way

          Error text:

          org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: unclassified field java.util.ArrayList text
          

          Reason: I guess it is a LazyMap feature that convert object to arrayList when you are trying to access multiple values with the same key.

          Should I create Jira issue with provided information? For me, it's hard to search for similar issues due to my language barrier. So I don't really know if there were such requests.

          Denis Andreev added a comment - - edited Thank you jglick ! Your answer have shed the light on my problem! To reproduce the error follow steps: 1) Create pipeline job 2) Definition -> pipeline script -> fill script with below code import groovy.json.* def jsonSlurper = new JsonSlurper() def json = jsonSlurper.parseText( '[{ "text" : "STATUS" },{ "text" : "BRIEF_DESCRIPTION" }]' ) echo json.text.toString() // With checkbox checked on "groovy sandbox" will cause 'unclassified' error echo json[ 'text' ].toString() // Will not cause the error in any way Error text: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: unclassified field java.util.ArrayList text Reason: I guess it is a LazyMap feature that convert object to arrayList when you are trying to access multiple values with the same key. Should I create Jira issue with provided information? For me, it's hard to search for similar issues due to my language barrier. So I don't really know if there were such requests.

          Jesse Glick added a comment -

          slowpoke working for me.

          [Pipeline] Start of Pipeline
          [Pipeline] echo
          STATUS
          [Pipeline] echo
          STATUS
          [Pipeline] End of Pipeline
          

          Perhaps you are running old versions of the script-security or workflow-cps plugins?

          Jesse Glick added a comment - slowpoke working for me. [Pipeline] Start of Pipeline [Pipeline] echo STATUS [Pipeline] echo STATUS [Pipeline] End of Pipeline Perhaps you are running old versions of the script-security or workflow-cps plugins?

          Denis Andreev added a comment - - edited

          jglick script security version: 1.34

          I have just realized that I didn't tell you anything about versions of my script security plugin and jenkins itself. I am so sorry about missing this information.

          Now it seems to be clear, probably this issue has been corrected in v 1.43

          Denis Andreev added a comment - - edited jglick script security version: 1.34 I have just realized that I didn't tell you anything about versions of my script security plugin and jenkins itself. I am so sorry about missing this information. Now it seems to be clear, probably this issue has been corrected in v 1.43

          Jesse Glick added a comment -

          1.43 just improved messages. But indeed the bug might have been fixed in some historical version. Since the stated version predates multiple security advisories, I do not see any reason to dig into it deeper. If there is still a particular problem reproducible in currently released plugin versions, it would be best to file a fresh issue. Groovy is a very complex language and there are surely some corner cases that have not yet been addressed.

          Jesse Glick added a comment - 1.43 just improved messages. But indeed the bug might have been fixed in some historical version. Since the stated version predates multiple security advisories, I do not see any reason to dig into it deeper. If there is still a particular problem reproducible in currently released plugin versions, it would be best to file a fresh issue. Groovy is a very complex language and there are surely some corner cases that have not yet been addressed.

          Denis Andreev added a comment -

          Seems that there is nothing else to talk about! Thank you for all that you have done!

          Denis Andreev added a comment - Seems that there is nothing else to talk about! Thank you for all that you have done!

            Unassigned Unassigned
            alex_ashitkin Alexander Ashitkin
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: