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

RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject getProperty java.lang.String (org.jenkinsci.plugins.workflow.cps.CpsClosure2.docker)

      Split off from JENKINS-30390.

      I ran 1.609.3, added Workflow: Aggregator and CloudBees Docker Workflow, created a flow

      node('master') {
        docker.withServer("tcp://0.0.0.0${env.GLADE_CATALOG_PATH}2375") { 
         docker.image("postgres:9.4.4").inside {
          sh "echo hello world"
         }
       }
      }
      

      with Use Groovy Sandbox checked. Then I got an error:

      org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject getProperty java.lang.String (org.jenkinsci.plugins.workflow.cps.CpsClosure2.docker)
      	at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:155)
      	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.rejectField(SandboxInterceptor.java:186)
      	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:172)
      	at org.kohsuke.groovy.sandbox.impl.Checker$4.call(Checker.java:153)
      	at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:150)
      	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:2)
      	at Unknown.Unknown(Unknown)
      	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.GeneratedMethodAccessor254.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:497)
      	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:145)
      	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19)
      	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
      	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
      	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:106)
      	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
      	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:164)
      	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:271)
      	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$000(CpsThreadGroup.java:71)
      	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:180)
      	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:178)
      	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47)
      	at ...
      

      Cannot reproduce in either Docker Workflow functional tests (with dependencies updated), or its demo (ditto).

          [JENKINS-30414] RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject getProperty java.lang.String (org.jenkinsci.plugins.workflow.cps.CpsClosure2.docker)

          Jesse Glick added a comment -

          Split off from JENKINS-30390.

          Jesse Glick added a comment - Split off from JENKINS-30390 .

          Jesse Glick added a comment -

          Probably related to JENKINS-30222.

          Jesse Glick added a comment - Probably related to JENKINS-30222 .

          Jesse Glick added a comment -

          Implementation of JENKINS-26135 probably introduced this.

          Jesse Glick added a comment - Implementation of JENKINS-26135 probably introduced this.

          Jesse Glick added a comment -

          Also cannot reproduce inside mvn -f docker-workflow hpi:run after applying attached update patch.

          Jesse Glick added a comment - Also cannot reproduce inside mvn -f docker-workflow hpi:run after applying attached update patch.

          Jesse Glick added a comment -

          Found it. In my test setup, script-security was already installed (bundled with Jenkins) and I neglected to restart after installing the new version, which is a mandatory dependency of new versions of Workflow. After the restart it is fine.

          Jesse Glick added a comment - Found it. In my test setup, script-security was already installed (bundled with Jenkins) and I neglected to restart after installing the new version, which is a mandatory dependency of new versions of Workflow. After the restart it is fine.

          Sean Flanigan added a comment -

          Thank you! I had no idea until I read that that installing plugins without restarting could break my builds.

          Sean Flanigan added a comment - Thank you! I had no idea until I read that that installing plugins without restarting could break my builds.

          Jesse Glick added a comment -

          Well the issue here was installing some plugins without restart which require an update of other plugins, which can only happen after restart. The Jenkins plugin manager is too dumb to handle this case properly. It does warn you in the UI to restart, but does not block the new plugins from being dynamically loaded. Maybe 2.19.x behaves better, have not checked yet.

          Jesse Glick added a comment - Well the issue here was installing some plugins without restart which require an update of other plugins, which can only happen after restart. The Jenkins plugin manager is too dumb to handle this case properly. It does warn you in the UI to restart, but does not block the new plugins from being dynamically loaded. Maybe 2.19.x behaves better, have not checked yet.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: