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

Job dsl and Authorize Project plugin is not working with "Sandbox" policy for executing groovy scripts.

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Not A Defect
    • Labels:
    • Environment:
    • Similar Issues:

      Description

      The issue we faced is job DSL plugin is not honoring groovy sandbox policies.

      we have installed structs plugin 1.13 version , Authorize Project plugin and Script Security plugin.


      Developer usually need to use "Sandbox" for executing groovy as it doesn't require any approval from administrators.


      We can see that this policy is working well in templates, pipelines and regular jobs. But it is failing when used in combination of "job dsl"and "Authorize Project plugin".


      This combination is expecting users who triggered job to have "Overall/RunScripts" access.This access cannot be given to developers.

      We configured job dsl to execute a groovy script in sandbox.

      For triggering this job, we used Authorization step with "Run as User who triggered Build".

       

      The build never executes and simply show waiting for next executor - even though that slave is idle.

       

      we can run the same build successfully as  admin and have "RunScripts" access. As developers we don't have this access and it is showing waiting for executor.

       

        Attachments

          Activity

          karthik_haluven karthik h v created issue -
          karthik_haluven karthik h v made changes -
          Field Original Value New Value
          Issue Type Task [ 3 ] Bug [ 1 ]
          karthik_haluven karthik h v made changes -
          Description {color:#1f497d}The issue we faced is job DSL plugin is not honoring groovy sandbox policies.{color}

          {color:#1f497d}we have installed structs plugin ** 1.13 version , Authorize Project plugin and Script Security plugin. {color}

          {color:#1f497d}Developer usually need to use "Sandbox" for executing groovy as it doesn't require any approval from administrators. {color}

          {color:#1f497d}We can see that this policy is working well in templates, pipelines and regular jobs. But it is failing when used in combination of "{color:#1f497d}{color:#1f497d}{color:#1f497d}job dsl"and "Authorize Project plugin". {color}{color}{color}{color}

          {color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}This combination is expecting users who triggered job to have "Overall/RunScripts" access.This access cannot be given to developers. {color}{color}{color}{color}

          {color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}We configured job dsl to execute a groovy script in sandbox. {color}{color}{color}{color}{color}{color}{color}{color}

          {color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}{color:#1f497d}For triggering this job, we used *Authorization* step with "Run as User who triggered Build".{color}{color}{color}{color}{color}{color}{color}{color}

           

          {color:#1f497d}The build never executes and simply show waiting for next executor - even though that slave is idle.{color}

           

          {color:#1f497d}we can run the same build successfully as  admin and have "RunScripts" access. As developers we don't have this access and it is showing waiting for executor.{color}

           
          {color:#1f497d}The issue we faced is job DSL plugin is not honoring groovy sandbox policies.{color}

          {color:#1f497d}we have installed structs plugin 1.13 version , Authorize Project plugin and Script Security plugin. {color}

          {color:#1f497d}Developer usually need to use "Sandbox" for executing groovy as it doesn't require any approval from administrators. {color}

          {color:#1f497d}We can see that this policy is working well in templates, pipelines and regular jobs. But it is failing when used in combination of "job dsl"and "Authorize Project plugin". {color}{color:#333333}
           
           This combination is expecting users who triggered job to have "Overall/RunScripts" access.This access cannot be given to developers.
           
           We configured job dsl to execute a groovy script in sandbox.
           
           For triggering this job, we used Authorization step with "Run as User who triggered Build".
           
            
           
           The build never executes and simply show waiting for next executor - even though that slave is idle.{color}

          {color:#333333} {color}

          {color:#333333}{color:#1f497d}we can run the same build successfully as  admin and have "RunScripts" access. As developers we don't have this access and it is showing waiting for executor.{color}{color}

          {color:#333333} {color}
          karthik_haluven karthik h v made changes -
          Description {color:#1f497d}The issue we faced is job DSL plugin is not honoring groovy sandbox policies.{color}

          {color:#1f497d}we have installed structs plugin 1.13 version , Authorize Project plugin and Script Security plugin. {color}

          {color:#1f497d}Developer usually need to use "Sandbox" for executing groovy as it doesn't require any approval from administrators. {color}

          {color:#1f497d}We can see that this policy is working well in templates, pipelines and regular jobs. But it is failing when used in combination of "job dsl"and "Authorize Project plugin". {color}{color:#333333}
           
           This combination is expecting users who triggered job to have "Overall/RunScripts" access.This access cannot be given to developers.
           
           We configured job dsl to execute a groovy script in sandbox.
           
           For triggering this job, we used Authorization step with "Run as User who triggered Build".
           
            
           
           The build never executes and simply show waiting for next executor - even though that slave is idle.{color}

          {color:#333333} {color}

          {color:#333333}{color:#1f497d}we can run the same build successfully as  admin and have "RunScripts" access. As developers we don't have this access and it is showing waiting for executor.{color}{color}

          {color:#333333} {color}
          {color:#333333}{color:#1f497d}The issue we faced is job DSL plugin is not honoring groovy sandbox policies.{color}{color}

          {color:#333333}{color:#1f497d}we have installed structs plugin 1.13 version , Authorize Project plugin and Script Security plugin. {color}{color}

          {color:#333333}{color:#1f497d}Developer usually need to use "Sandbox" for executing groovy as it doesn't require any approval from administrators. {color}{color}

          {color:#333333}{color:#1f497d}We can see that this policy is working well in templates, pipelines and regular jobs. But it is failing when used in combination of "job dsl"and "Authorize Project plugin". {color}{color}{color:#333333}
           
           This combination is expecting users who triggered job to have "Overall/RunScripts" access.This access cannot be given to developers.
           
           We configured job dsl to execute a groovy script in sandbox.
           
           For triggering this job, we used Authorization step with "Run as User who triggered Build".
           
            
           
           The build never executes and simply show waiting for next executor - even though that slave is idle.{color}

          {color:#333333} {color}

          {color:#333333}we can run the same build successfully as  admin and have "RunScripts" access. As developers we don't have this access and it is showing waiting for executor.{color}
           
            
          daspilker Daniel Spilker made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Not A Defect [ 7 ]
          daspilker Daniel Spilker made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              daspilker Daniel Spilker
              Reporter:
              karthik_haluven karthik h v
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: