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)

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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).

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Split off from JENKINS-30390.

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

            Probably related to JENKINS-30222.

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

            Implementation of JENKINS-26135 probably introduced this.

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

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

            Show
            jglick Jesse Glick added a comment - Also cannot reproduce inside mvn -f docker-workflow hpi:run after applying attached update patch.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            seanf Sean Flanigan added a comment -

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

            Show
            seanf Sean Flanigan added a comment - Thank you! I had no idea until I read that that installing plugins without restarting could break my builds.
            Hide
            jglick 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.

            Show
            jglick 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.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: