Details
-
Bug
-
Status: Resolved (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
-
Jenkins 2.3 from Docker Hub, Pipeline Plugin 2.0
-
-
workflow-cps 2.67
Description
When using
new GetMethod(url)
from
import org.apache.commons.httpclient.HttpClient
import org.apache.commons.httpclient.methods.GetMethod
directly in a Workflow script pasted into the UI, everything works as expected.
When the script is loaded with the file loader plugin during the Workflow script, the following error occurs:
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use new org.apache.commons.httpclient.methods.GetMethod java.lang.String
No pending script approval is generated.
Attachments
Issue Links
- causes
-
-
- Closed
-
- is duplicated by
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
- relates to
-
JENKINS-33614 Link to script approval from build console
-
- Resolved
-
- links to
Activity
Only thing that comes to mind at first glance is maybe having SandboxContinuable#findRejectedAccessException actually traverse the flow graph looking for a RejectedAccessException anywhere? Though I guess that wouldn't actually show up there if it's caught, which is the whole problem here.
The minimal test case (thanks to abayer in JENKINS-40333) is
catchError {Jenkins.instance}
From inspecting the issue in a debugger, it is clear that Continuable.run0 is simply too coarse-grained for this purpose: it is designed to keep stepping through the program until it needs to yield, whereas a RejectedAccessException could be thrown and caught inside a single CPS VM chunk.
So I am again looking into deprecating ScriptApproval.accessRejected and just making the approval entry addition be automatic at the call site. This will require a new API which callers like workflow-cps would need to opt in to. At the same time I think I could move ScriptApprovalNote into script-security so it would be available for all plugins, not just Pipeline. The net effect would be an API that it is both easier to use and more reliable.
William Will
added a comment - I will note that I was using a Jenkins pipeline and was having this issue when putting scripts in the Jenkins "failure" block, though not within a catch. It would seem that the "failure" block is implicitly a catch block. The workaround for me was running the script arbitrarily in one of the steps of the pipeline, so that it would come up in script approval, then moving it back to the failure block.
William Will
added a comment - I will note that I was using a Jenkins pipeline and was having this issue when putting scripts in the Jenkins "failure" block, though not within a catch. It would seem that the "failure" block is implicitly a catch block. The workaround for me was running the script arbitrarily in one of the steps of the pipeline, so that it would come up in script approval, then moving it back to the failure block. 
leemeador
added a comment - Same thing happens when the rejected code is in the initialization code to give a @Field its value. I suspect it becomes a static variable and the exception gets swallowed because its in the initialization for the class or called from inside, so to speak, the constructor.
I used a line like this at the top of the script
@Field List<String> list = [''] * 21
leemeador
added a comment - Same thing happens when the rejected code is in the initialization code to give a @Field its value. I suspect it becomes a static variable and the exception gets swallowed because its in the initialization for the class or called from inside, so to speak, the constructor.
I used a line like this at the top of the script
@Field List<String> list = [''] * 21 
abayer Could you please TAL?