-
Bug
-
Resolution: Fixed
-
Minor
-
Jenkins 2.7.1, CloudBees Docker Pipeline 1.7
Steps to reproduce:
- Start with a fresh Jenkins installation (reproduced on both 2.7.1 LTS and 2.16(
- Install suggested plugins
- Install CloudBees Docker Pipeline plugin (1.7)
- Create a Pipeline project with the snippet below
- Run Pipeline, see exception below.
node {
docker.image.inside('ubuntu:trusty') {
}
}
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject getProperty java.lang.String (org.jenkinsci.plugins.docker.workflow.Docker.image) at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:181) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor$11.reject(SandboxInterceptor.java:312) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:363) at org.kohsuke.groovy.sandbox.impl.Checker$4.call(Checker.java:241) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:238) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:23) at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:17) at WorkflowScript.run(WorkflowScript:4) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:62) at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:58) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:32) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:29) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:29) at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:164) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:360) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:236) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:226) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Finished: FAILURE
Note: The Pipeline project does, by default, have Groovy Sandbox checked (see screenshot). I have also reproduced this after restarting Jenkins to make sure there aren't any live-loading issues with the plugins.
- is duplicated by
-
-
- Resolved
-
- relates to
-
-
- Reopened
-
- links to
[JENKINS-37129] Sandbox RejectedAccessException when using docker.image.inside() stupidly
| Summary | Original: Sandbox | New: Sandbox RejectedAccessException when using docker.image.inside() out-of-the-box |
| Priority | Original: Major [ 3 ] | New: Minor [ 4 ] |
| Summary | Original: Sandbox RejectedAccessException when using docker.image.inside() out-of-the-box | New: Sandbox RejectedAccessException when using docker.image.inside() stupidly |
| Labels | Original: community-bee | New: community-bee diagnostics |
| Epic Link | New: JENKINS-35396 [ 171189 ] |
script-security does not know for sure whether you just mistyped a method name (or, as in this case, omitted an argument) or were genuinely trying to call a Groovy dynamic method—which would never be allowed in the sandbox. It does include information about what you were apparently trying to call in the exception message, but perhaps it should expand the message to emphasize that this would be a routine consequence of such a mistake.
| Component/s | New: script-security-plugin [ 18520 ] | |
| Component/s | Original: docker-workflow-plugin [ 20625 ] |
| Link |
New:
This issue is duplicated by |
| Link | New: This issue relates to JENKINS-35352 [ JENKINS-35352 ] |
So I have sobered up a little more and realized that my Pipeline script was wrong and I should have been invoking docker.image('ubuntu:trusty').inside instead.
I am still leaving the ticket here because IMO there still is a usability bug around using the Docker Pipeline plugin provided DSL and the error messages shown.