-
Bug
-
Resolution: Fixed
-
Blocker
-
None
-
Jenkins 2.60.2 .war on Ubuntu
Script Security Plugin 1.31
Groovy Plugin 2.0
Steps to reproduce:
Run Jenkins 2.60.2 with latest Script Security Plugin (1.31). Create a freestyle job that runs a system groovy script from a script file /tmp/minimal.groovy (!, bug does not appear if the script is defined in the job itself).
Sample job config.xml is attached.
Contents of /tmp/minimal.groovy :
java.util.regex.Matcher m = "asdf" =~ /(a)/
Run the job.
Observed result
ERROR: Build step failed with exception org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: unclassified staticMethod org.kohsuke.groovy.sandbox.impl.Checker checkedStaticCall java.lang.Class java.lang.String java.lang.String java.lang.String at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onStaticCall(SandboxInterceptor.java:146) at org.kohsuke.groovy.sandbox.impl.Checker$2.call(Checker.java:184) at org.kohsuke.groovy.sandbox.impl.Checker.checkedStaticCall(Checker.java:188) at org.kohsuke.groovy.sandbox.impl.Checker$checkedStaticCall$1.callStatic(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:222) at Script1.run(Script1.groovy:1) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.run(GroovySandbox.java:141) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript.evaluate(SecureGroovyScript.java:165) at hudson.plugins.groovy.SystemGroovy.run(SystemGroovy.java:95) at hudson.plugins.groovy.SystemGroovy.perform(SystemGroovy.java:59) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:735) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:490) at hudson.model.Run.execute(Run.java:1735) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:405)
Expected result
Script runs without error.
Known mitigations
Changing the script to:
def m = "asdf" =~ /(a)/
That is, removing the explicit type declaration solves the problem.
Also, copying the script into the job definition doesn't trigger the error.
Priority
Since the explicit type declaration is not idiomatic usage anyways and the workaround is simple, I don't think it's highly important but would like to understand why this fails in any case.
- is duplicated by
-
-
- Closed
-
- links to
[JENKINS-46088] unclassified staticMethod when assigning java.util.regex.Matcher in included script
Urs Schoenenberger
created issue -
| Priority | Original: Minor [ 4 ] | New: Critical [ 2 ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
Unless someone (hint jglick) discovers a flaw in my reasoning, I'm pretty sure I've found the problem and have a fix for it. We are double-transforming cast expressions currently, resulting in us transforming the actual sandbox code itself! Ow. So, at https://github.com/jenkinsci/groovy-sandbox/pull/37 (with associated follow-on test at https://github.com/jenkinsci/script-security-plugin/pull/139), I fix that.
Note that there's no groovy-cps or workflow-cps-plugin downstream PR/test - that's because SandboxTransformer from groovy-sandbox, where the problem is, is not used by CPS transformation. CPS code is sandboxed using groovy-cps's SandboxInvoker.
| Remote Link | New: This issue links to "groovy-sandbox PR #37 (Web Link)" [ 17434 ] |
| Assignee | New: Andrew Bayer [ abayer ] |
| Remote Link | New: This issue links to "script-security PR #139 (Web Link)" [ 17435 ] |
groovy-cps does use SandboxTransformer for some purposes, so to be on the safe side you do need to have at least a downstream PR in workflow-cps verifying correct behavior in Pipeline.
I saw something along these lines yesterday, where a non-Pipeline sandboxed script was complaining about things like:
So...somehow, the latest updates to groovy-sandbox and/or script-security are resulting in the sandbox code itself getting sandboxed. Which is...weird. More investigation is needed, but I think this is important.