-
Bug
-
Resolution: Not A Defect
-
Minor
-
None
-
Jenkins 2.19.4, plugin version: 1.24
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.
- is related to
-
-
- Resolved
-
[JENKINS-40334] Need to bypass security checks on Groovy scripts (full API)
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.
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. 
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.