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

Need to bypass security checks on Groovy scripts (full API)

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Not A Defect
    • Component/s: script-security-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.19.4, plugin version: 1.24
    • Similar Issues:

      Description

      Suggestion: Provide a way to completely bypass the security checks on Groovy scripts in the plugin's configuration (not just a sandbox mode...).

      Rationale: For many internal uses of Jenkins, security is managed through permission access tables, there is no need for this extra burden, especially because it raises issues with DSL-generated projects (see below).

      Note on DSL Projects: If the DSL contains parametrized Groovy code, each generated Groovy code has to be approved individually, which is very difficult if at all possible to manage.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            If you are referring to Pipeline scripts (the issue summary does not say, and there are many plugins using this API), you can configure a job to run without the sandbox. But generally I do not recommend it.

            Show
            jglick Jesse Glick added a comment - If you are referring to Pipeline scripts (the issue summary does not say, and there are many plugins using this API), you can configure a job to run without the sandbox. But generally I do not recommend it.
            Hide
            pnobili Philippe Nobili added a comment -

            I was not referring to that, sorry about the confusion, I'll try to make it clearer: When using Groovy code in DSL projects, we end-up with many scripts to finally approve (e.g. after variable expansions while processing the DSL), although logically, we actually wrote very few scripts...

            This ends up with a situation virtually impossible to manage. The way I understand it, the problem comes from the coupling between the script-permission plugin and other plugins that we use. In short, we have "to buy" the permission plugin although we do not need it.

            It might be not a defect, but a way to "de-activate" the plugin (or remove the coupling...) would be welcome: we develop an interval service and manage permissions using permission tables / logins. We do not need the script approval mechanism...

            I hope it makes it clearer.
            Best.

            Show
            pnobili Philippe Nobili added a comment - I was not referring to that, sorry about the confusion, I'll try to make it clearer: When using Groovy code in DSL projects, we end-up with many scripts to finally approve (e.g. after variable expansions while processing the DSL), although logically, we actually wrote very few scripts... This ends up with a situation virtually impossible to manage. The way I understand it, the problem comes from the coupling between the script-permission plugin and other plugins that we use. In short, we have "to buy" the permission plugin although we do not need it. It might be not a defect, but a way to "de-activate" the plugin (or remove the coupling...) would be welcome: we develop an interval service and manage permissions using permission tables / logins. We do not need the script approval mechanism... I hope it makes it clearer. Best.

              People

              • Assignee:
                Unassigned
                Reporter:
                pnobili Philippe Nobili
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: