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
reg leg
added a comment - 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.
reg leg
added a comment - 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.
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
We got the same issue in 1.7.7. This issue blocks updating your Jenkins server. Do you planning to resolve this issue in nearest time or it will be better do not rely on this.