Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
Jenkins 2.258
job-dsl plugin 1.77
script-security plugin 1.75
Description
The upgrade of script-security plugin from 1.74 to 1.75 broke the behavior of existing Job Dsl jobs. This occurs when the Job Dsl is run in a sandbox and uses a "configure {" closure.
The following example pipelineJob script recreates the problem:
node('master') { stage('jobDsl configure test') { jobDsl( sandbox: true, scriptText: ''' pipelineJob('test-configure-job') configure { node -> node.append(test('Testing...')) } } ''', ) } }
When this script is run in a sandbox, with "Enable script security for Job DSL scripts" checked, it fails with the following:
Processing provided DSL script java.lang.SecurityException: Rejecting unsandboxed method call: javaposse.jobdsl.dsl.jobs.WorkflowJob.invokeMethod(java.lang.String, [Ljava.lang.Object;) at org.kohsuke.groovy.sandbox.impl.RejectEverythingInterceptor.onMethodCall(RejectEverythingInterceptor.java:44) at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:161) at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:165) at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:135) at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:135) at org.kohsuke.groovy.sandbox.impl.Checker$checkedCall$0.callStatic(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194) at script$_run_closure1$_closure2.doCall(script:3) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566)
This does not happen with script-security plugin version 1.74.
Attachments
Activity
this issue breaks completely the Multibranch pipeline jobs, because of https://issues.jenkins.io/browse/JENKINS-60874 the only way to configure the pull request discovery settings is a configure block, after jobDSL 1.75 it is not possible to configure pull request discovery settings anymore
configure {
// workaround for JENKINS-60874, JENKINS-57942, and JENKINS-46202
// Discovers pull requests where the origin repository is the same as the target repository.
// https://github.com/jenkinsci/github-branch-source-plugin/blob/master/src/main/java/org/jenkinsci/plugins/github_branch_source/OriginPullRequestDiscoveryTrait.java#L57-L72
def traits = it / sources / data / 'jenkins.branch.BranchSource' / source / traits
traits << 'org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait' {
strategyId 1
trust(class: 'org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission')
}
traits << 'org.jenkinsci.plugins.github__branch__source.OriginPullRequestDiscoveryTrait' {
strategyId 1
}
}
I have no time to work on this myself, but https://github.com/jenkinsci/job-dsl-plugin/compare/master...dwnusbaum:JENKINS-63788 (untested, and I have never used job-dsl, so beware!) could be used as a starting point for a possible fix using the approach I described here if someone is interested. Whether that approach really makes sense, I am not sure, because I do not understand exactly how users configure the sandboxed code in question or the contexts in which it may be executed.
I know this doesn't fix the issue and may not be the best suggestion, but it may unblock people.
Unchecking Configure Global Security -> Enable script security for Job DSL scripts allows you use configure
Aitor Pazos
added a comment - - edited I know this doesn't fix the issue and may not be the best suggestion, but it may unblock people.
Unchecking Configure Global Security -> Enable script security for Job DSL scripts allows you use configure 
Hi all.
dnusbaum , first thanks for your investigations.
We rely a lot on this jobdsl feature, and I don't have any workaround for that. You was looking for for a jobdsl maintainer, is there any kind of process to find one and can we hope a fix for this bug ?
Otherwise any kind of workarround for this ( rest api to generate folders/jobs also doesn't work for me: other problem with oauth/folder authorizations bug).
If I could help, I would but this is really out of my skills.
If anyone has any idea about the time needed to solve this issue, I'm very interested.