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

Restricted sandbox breaks Callable sugar

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: script-security-plugin
    • Labels:
      None
    • Environment:
      Jenkins v2.84, Pipeline: Groovy v2.41
    • Similar Issues:

      Description

      Here's a minimal example that works outside of sandbox but fails in sandbox:

      def func = { 1 }; 
      this.func2 = { 1 }; 
      assert 1 == func(); 
      assert 1 == func2.call(); 
      assert 1 == func2(); // this line fails 

      It appears as if the it.call() -> it() syntactic sugar, which afaik is part of the language spec, is not honored in restricted sandbox under certain circumstances that make it difficult to create dynamic functions; ideally, I'd like to do something resembling:

      def files = sh(returnStdout:true,script:'ls vars/*.groovy'}.trim();
      for(file in files){this."${file.subscript(5,file.size()-7)}" = load file; }

      Unlike method signatures which can be whitelisted, because this is a language feature it does not appear to be possible to enable.

        Attachments

          Issue Links

            Activity

            Hide
            fspieler_bloomberg Fred Spieler added a comment -

            It seems that this is by design of restricted sandbox.

            Show
            fspieler_bloomberg Fred Spieler added a comment - It seems that this is by design of restricted sandbox.
            Hide
            fspieler_bloomberg Fred Spieler added a comment -

            Sorry, on second thought, I believe this is still a bug; if it's possible to overwrite WorkflowScript variables in restricted sandbox it should be fine to make the callable syntax functional.

            I'm clearly on the fence between bug and feature, but leaning towards bug.

            Show
            fspieler_bloomberg Fred Spieler added a comment - Sorry, on second thought, I believe this is still a bug; if it's possible to overwrite WorkflowScript variables in restricted sandbox it should be fine to make the callable syntax functional. I'm clearly on the fence between bug and feature, but leaning towards bug.
            Hide
            abayer Andrew Bayer added a comment -

            Well, that's interesting - it works in a sandboxed Pipeline script, but not in a sandboxed system Groovy step in a freestyle job. Weeeeeird.

            Show
            abayer Andrew Bayer added a comment - Well, that's interesting - it works in a sandboxed Pipeline script, but not in a sandboxed system Groovy step in a freestyle job. Weeeeeird.
            Hide
            abayer Andrew Bayer added a comment -
            Show
            abayer Andrew Bayer added a comment - Got a PR for this at https://github.com/jenkinsci/script-security-plugin/pull/211

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                fspieler_bloomberg Fred Spieler
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: