[JIRA] [workflow-plugin] (JENKINS-28178) Option to disable sandbox in CpsScmFlowDefinition

506 views
Skip to first unread message

lars.bilke@ufz.de (JIRA)

unread,
Aug 13, 2015, 3:40:05 AM8/13/15
to jenkinsc...@googlegroups.com
Lars Bilke edited a comment on Improvement JENKINS-28178
 
Re: Option to disable sandbox in CpsScmFlowDefinition
Can you please explain the workaround in more detail? I tried to use the method you mention in the tutorial:

{{
def flow
node('slave') {
    git '…'
    flow = load 'flow.groovy'
    flow.devQAStaging()
}
flow.production()
}}

But {{flow.groovy}} is still run in the sandbox.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

lars.bilke@ufz.de (JIRA)

unread,
Aug 13, 2015, 3:40:06 AM8/13/15
to jenkinsc...@googlegroups.com

lars.bilke@ufz.de (JIRA)

unread,
Aug 13, 2015, 3:41:02 AM8/13/15
to jenkinsc...@googlegroups.com
Lars Bilke edited a comment on Improvement JENKINS-28178

lars.bilke@ufz.de (JIRA)

unread,
Aug 13, 2015, 3:42:02 AM8/13/15
to jenkinsc...@googlegroups.com
Lars Bilke edited a comment on Improvement JENKINS-28178
Can you please explain the workaround in more detail? I tried to use the method you mention in the tutorial:
``` {code:groovy}
def flow
node('slave') {
    git '…'
    flow = load 'flow.groovy'
    flow.devQAStaging()
}
flow.production()
``` {code}

But {{flow.groovy}} is still run in the sandbox.

lars.bilke@ufz.de (JIRA)

unread,
Aug 13, 2015, 3:43:01 AM8/13/15
to jenkinsc...@googlegroups.com
Lars Bilke edited a comment on Improvement JENKINS-28178
Can you please explain the workaround in more detail? I tried to use the method you mention in the tutorial:

{code: groovy java }

def flow
node('slave') {
    git '…'
    flow = load 'flow.groovy'
    flow.devQAStaging()
}
flow.production()
{code}

But {{flow.groovy}} is still run in the sandbox.

jglick@cloudbees.com (JIRA)

unread,
Aug 13, 2015, 2:59:02 PM8/13/15
to jenkinsc...@googlegroups.com

Lars Bilke well of course you would need to uncheck the sandbox option in the job configuration too.

lars.bilke@ufz.de (JIRA)

unread,
Aug 14, 2015, 1:50:01 AM8/14/15
to jenkinsc...@googlegroups.com

Is this also possible on a Workflow Multibranch job?

jglick@cloudbees.com (JIRA)

unread,
Aug 21, 2015, 12:31:01 PM8/21/15
to jenkinsc...@googlegroups.com

No, currently multibranch does reuse CpsScmFlowDefinition including the forced sandbox=true.

Probably this needs to be handled in that case using a BranchProperty: while you may be comfortable permitting unsandboxed execution from Jenkinsfile contents in origin/master, you would not want to allow that in a pull request on a publicly visible repository. TBD what the policy should be: allowing a customized Jenkinsfile if run in the sandbox, or just pinning a Jenkinsfile from the base branch you control.

In other words, I consider the multibranch variant of this issue to be distinct.

eholzwarth@littlegreensoftware.com (JIRA)

unread,
Oct 16, 2015, 2:38:01 PM10/16/15
to jenkinsc...@googlegroups.com

Jesse Glick Is there a separate issue created for the multibranch variant of this issue?

We are using the global workflow library. The setup was working with a standard workflow, but getting a RejectedAccessException after switching to the multibranch workflow which I understand from your comment forces groovy sandbox mode.

org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: unclassified field java.util.ArrayList name
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.rejectField(SandboxInterceptor.java:182)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:174)

How can I authorize the properties our workflow expects so that we can use the multibranch workflow?

eholzwarth@littlegreensoftware.com (JIRA)

unread,
Oct 16, 2015, 2:39:02 PM10/16/15
to jenkinsc...@googlegroups.com
Ed Holzwarth edited a comment on Improvement JENKINS-28178
[~jglick] Is there a separate issue created for the multibranch variant of this issue? 


We are using the global workflow library. The setup was working with a standard workflow, but getting a {{RejectedAccessException}} after switching to the multibranch workflow which I understand from your comment forces groovy sandbox mode.

{code:java}
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: unclassified field java.util.ArrayList name
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.rejectField(SandboxInterceptor.java:182)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:174)
{code}

How can I authorize the properties our workflow expects so that we can use the multibranch workflow?

eholzwarth@littlegreensoftware.com (JIRA)

unread,
Oct 17, 2015, 10:22:05 AM10/17/15
to jenkinsc...@googlegroups.com

PS - the lines that trigger RejectedAccessExceptions with our multibranch workflow are as follows:

	// triggers RejectedAccessException: unclassified field java.util.ArrayList name
	def choices = skipDeploy + "\n" config.deployTargets*.name.join('\n')

and

	// triggers RejectedAccessException: Scripts not permitted to use staticMethod 
	def selectedTarget = config.deployTargets.findResult({ it.name == deployTarget ? it : null })

eholzwarth@littlegreensoftware.com (JIRA)

unread,
Oct 17, 2015, 10:24:02 AM10/17/15
to jenkinsc...@googlegroups.com
Ed Holzwarth updated an issue
 
Jenkins / Improvement JENKINS-28178
Change By: Ed Holzwarth
Priority: Minor Major

jglick@cloudbees.com (JIRA)

unread,
Oct 19, 2015, 3:27:04 PM10/19/15
to jenkinsc...@googlegroups.com
Jesse Glick commented on Improvement JENKINS-28178
 
Re: Option to disable sandbox in CpsScmFlowDefinition

The ArrayList.name issue sounds like a bug in script-security which was already fixed; make sure you are running the latest version. It is possible you found a new corner case, of course. Best to report it in a separate issue with a standalone reproducible test case if you can come up with one.

findResult could be whitelisted but it is probably not going to work anyway (with or without the sandbox) due to JENKINS-26481. At least I am guessing that is the method you are talking about; the exception message was apparently truncated.

jglick@cloudbees.com (JIRA)

unread,
Nov 17, 2015, 2:04:04 PM11/17/15
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
 
Change By: Jesse Glick
Currently {{CpsScmFlowDefinition}} enforces sandbox mode on the grounds that whole-script approval is unrealistic (an administrator would need to approve every SCM revision, and Jenkins cannot automatically approve revisions like it could from GUI changes to a {{CpsFlowDefinition}} by an administrator).

There should however be an option to simply trust the script as it comes from the SCM. This could be checked by default if Jenkins were unsecured; for a secured Jenkins, the default should remain to use the sandbox, though you could switch to trusted mode with a stern warning in form validation explaining that you are responsible for auditing all changes to that SCM repository, and noting that attackers with SCM access could take over control of Jenkins in ways that might make auditing difficult. (For example, someone with push access to a Git repository could push a script which obtains the API token of a legitimate Jenkins administrator, mails it to the attacker, then deletes the current build record; and finally force-push the attacking script out of existence except via the reflog.)

Pending such an option, the workaround is given by the tutorial [here|https://github.com/jenkinsci/workflow-plugin/blob/master/TUTORIAL.md# triggering- manual-loading]: define a {{CpsFlowDefinition}} with an approved script that checks out the SCM and uses {{load}} to run it. This has the same effect at the price of more awkward configuration.

bc.fisher@yahoo.com (JIRA)

unread,
Jan 27, 2016, 7:13:06 PM1/27/16
to jenkinsc...@googlegroups.com
Brent Fisher commented on Improvement JENKINS-28178
 
Re: Option to disable sandbox in CpsScmFlowDefinition

FWIW, we are running into the same multibranch RejectedAccessExceptions from simple string manipulation. I almost think it could be useful to have the possibility of a whitelist extension file. I.e. methods that I feel are safe for my own Jenkins instance.
And perhaps a way to mark which branches require sandboxing, or a way to not sandbox a pull request, if the script hasn't changed? Its pretty tricky, as you say.
You mentioned that this is a unique issue. Is there already logged a ticket for this multibranch situation?

bc.fisher@yahoo.com (JIRA)

unread,
Jan 27, 2016, 7:15:07 PM1/27/16
to jenkinsc...@googlegroups.com
Brent Fisher edited a comment on Improvement JENKINS-28178
FWIW, we are running into the same multibranch RejectedAccessExceptions from simple string manipulation.


org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method java.lang.String substring int

  I almost think it could be useful to have the possibility of a whitelist extension file.  I.e. methods that I feel are safe for my own Jenkins instance.
And perhaps a way to mark which branches require sandboxing, or a way to not sandbox a pull request, if the script hasn't changed?  Its pretty tricky, as you say.
You mentioned that this is a unique issue.  Is there already logged a ticket for this multibranch situation?

jglick@cloudbees.com (JIRA)

unread,
Mar 21, 2016, 6:18:03 PM3/21/16
to jenkinsc...@googlegroups.com

I almost think it could be useful to have the possibility of a whitelist extension file. I.e. methods that I feel are safe for my own Jenkins instance.

Manage Jenkins » In-process Script Approvals

just pinning a Jenkinsfile from the base branch you control

Already implemented in the case of the GitHub branch source, so I do not suppose anything special need be done for multibranch support other than a higher-level option to disable the sandbox that would get propagated down to the branch projects.

sgiterman@gmail.com (JIRA)

unread,
Apr 18, 2016, 11:44:02 AM4/18/16
to jenkinsc...@googlegroups.com
gitt commented on Improvement JENKINS-28178

We develop Pipeline scripts (stored in SCM) using staging Jenkins instance and then use them on multiple production Jenkins instances. To do this we need to re-approve all methods one by one again on each of production Jenkins (including such non-harmful methods like "java.lang.String equalsIgnoreCase java.lang.String" or "java.util.Map containsKey java.lang.Object").

Would it be possible for the administrator user to export the list off all approvals from one Jenkins and import them to another instance (just copying scriptApproval.xml seems not to work because of hash)? If only administrator is allowed to do it, it would be secure since he could review the file before uploading and only previously approved methods would be allowed.

pwolf@cloudbees.com (JIRA)

unread,
Apr 19, 2016, 12:28:03 PM4/19/16
to jenkinsc...@googlegroups.com

gitt You can update the whitelist with a plugin:

@Extension
    public static class MiscWhitelist extends ProxyWhitelist {
        /**
         * Methods to add to the script-security whitelist for this plugin to work.
         *
         * @throws IOException
         */
        public MiscWhitelist() throws IOException {
            super(new StaticWhitelist(
                    "method java.util.Map containsKey java.lang.Object",
                    "method java.lang.Class isInstance java.lang.Object"
         }
  }

If you encapsulate your whitelist in a plugin then you simply need to install the plugin on each master where you want to apply it.

faheem@cliqz.com (JIRA)

unread,
Apr 29, 2016, 10:07:02 AM4/29/16
to jenkinsc...@googlegroups.com

Hi I have some jenkinfiles which worked perfectly when I just copied them to a simple pipeline job. After shifting to a multibranch or jenkinsfile from scm all of them get a rejected access exception, which makes sense due to groovy sand boxing

ERROR: Failed: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use new java.util.HashMap

on a command, which is just parsing an xml from a get with curl

13:55:28 + xmllint --xpath string(//action/cause/shortDescription) JENKINS_REST_API_RESULTS
[Pipeline] readFile
[Pipeline] error
[Pipeline] echo

My problem is I have admin privileges for jenkins. I also have permission to read/RunScripts in Overall, but I still don't see an approval request for "java.util.HashMap" in scriptApproval section.

At one point I had approvals due to my testing but now what ever I try e.g. moving the job a simple pipeline enabling sandboxing, creating a multibranch, loading the jenkinsfile through scm, nothing triggers a script approval for "java.util.HashMap". Which I am not even sure I require because I am the admin my self, who is creating these jobs.

And I see no way to whitelist certain methods my self, until or unless as Patrick Wolf mentioned to create a plugin and install it.
Is there any solution for this currently. And I totally vote for a disabled or a limited sandboxed environment, with the choice easily accessible from the configuration.

faheem@cliqz.com (JIRA)

unread,
Apr 29, 2016, 10:18:02 AM4/29/16
to jenkinsc...@googlegroups.com
Faheem Nadeem edited a comment on Improvement JENKINS-28178
Hi I have some jenkinfiles which worked perfectly when I just copied them to a simple pipeline job. After shifting to a multibranch or jenkinsfile from scm all of them get a rejected access exception, which makes sense due to groovy sand boxing

{code:java}

ERROR: Failed: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use new java.util.HashMap
{code}


on a command, which is just parsing an xml from a get with curl

{code:java}

13:55:28 + xmllint --xpath string(//action/cause/shortDescription) JENKINS_REST_API_RESULTS
[Pipeline] readFile
[Pipeline] error
[Pipeline] echo
{code}


My problem is I have admin privileges for jenkins. I also have permission to read/RunScripts in Overall, but I still don't see an approval request for "java.util.HashMap" in scriptApproval section. 

At one point I had approvals due to my testing  but , which I accepted. But  now what ever I try e.g. moving the job a simple pipeline enabling sandboxing, creating a multibranch, loading the jenkinsfile through scm, nothing triggers a script approval for "java.util.HashMap".  Which  To top it all  I  removed the previously approved requests and now even they are not triggered :( Interestingly, I  am not even sure  why  I require  because  approvals as  I am the admin my self, who is creating these jobs. 

And I see no way to whitelist certain methods my self, until or unless as [~hrmpw] mentioned to create a plugin and install it. 

Is there any solution for this currently. And I totally vote for a disabled or a limited sandboxed environment, with the choice easily accessible from the configuration. 

danny@kirchmeier.us (JIRA)

unread,
May 26, 2016, 2:08:09 AM5/26/16
to jenkinsc...@googlegroups.com

I ended up recompiling the plugin with the sandbox option set to false. It's fragile, but it got the job done on my jenkins instance.

I published my fork along with instructions to https://github.com/danthegoodman/workflow-cps-plugin/tree/disable_scm_security if anyone else want to use it.

v.gimple@stemmer-imaging.de (JIRA)

unread,
Jul 29, 2016, 4:46:09 AM7/29/16
to jenkinsc...@googlegroups.com

Thank you Danny - you made my day!
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

jglick@cloudbees.com (JIRA)

unread,
Aug 29, 2016, 1:56:08 PM8/29/16
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
Change By: Jesse Glick
Component/s: workflow-cps-plugin
Component/s: pipeline

jglick@cloudbees.com (JIRA)

unread,
Aug 29, 2016, 1:58:07 PM8/29/16
to jenkinsc...@googlegroups.com
Jesse Glick commented on Improvement JENKINS-28178
 
Re: Option to disable sandbox in CpsScmFlowDefinition

Faheem Nadeem whatever your issue is, it is not this.

Given JENKINS-31155 and its supported for trusted libraries which wrap otherwise unsafe calls, I am even less inclined to touch this.

james.ray@capitalone.com (JIRA)

unread,
Sep 1, 2016, 10:01:20 AM9/1/16
to jenkinsc...@googlegroups.com
Jimmy Ray edited a comment on Improvement JENKINS-28178
So, I know I am late to the party on this one, but we have been struggling with similar issues, making choices whether or not to use ` ` CpsScmFlowDefinition` ` or `CpsFlowDefinition`.  And it comes down to forced sandbox.  We considered rewriting the plugin, but we don't see that as a sustainable approach.  There are a lot of additional functionality that we would like to use.  I understand the security concerns around allowing sandbox behavior to be disabled at the job level.  It's the tug-of-war between DEV and OPS.  However, I would love to have this functionality.  

Is toggling the sandbox behavior for `CpsScmFlowDefinition` being considered?

james.ray@capitalone.com (JIRA)

unread,
Sep 1, 2016, 10:01:22 AM9/1/16
to jenkinsc...@googlegroups.com

james.ray@capitalone.com (JIRA)

unread,
Sep 1, 2016, 10:02:08 AM9/1/16
to jenkinsc...@googlegroups.com
Jimmy Ray edited a comment on Improvement JENKINS-28178

james@sandlininc.com (JIRA)

unread,
Oct 4, 2016, 12:22:10 PM10/4/16
to jenkinsc...@googlegroups.com

Yeah we have a very small team that manages builds for 400+ DEV & QA. Our scripts & servers are a locked down (2FA) environment to which only 5 people have access. If I can trust these 5 people with root access to a Fortune 500 company's production systems, I think I can trust them in Jenkins.

Having Jenkins in this locked down environment, we are obligated to provide data to developers via in house scripting. Sadly we must write apps that run outside Jenkins to get data via the REST API and process for display. With the capabilities of Java sitting there behind our Pipeline scripts, it's very frustrating I can't utilize said capabilities.

james@sandlininc.com (JIRA)

unread,
Oct 4, 2016, 12:24:02 PM10/4/16
to jenkinsc...@googlegroups.com
James Sandlin edited a comment on Improvement JENKINS-28178
Yeah we have a very small team that manages builds for 400+ DEV & QA. Our scripts & servers are a locked down (2FA) environment to which only 5 people have access. If I can trust these 5 people with root access to a Fortune 500 company's production systems, I think I can trust them in Jenkins.

Having Jenkins in this locked down environment, we are obligated to provide data to developers via in house scripting. Sadly we must write apps that run outside Jenkins to get data via the REST API and process for display. With the capabilities of Java sitting there behind our Pipeline scripts, it's very frustrating I can't utilize said capabilities.


Another option: Allow wildcards in the exception list so I can just add .* as allowed.

pwolf@cloudbees.com (JIRA)

unread,
Oct 4, 2016, 7:54:13 PM10/4/16
to jenkinsc...@googlegroups.com

Regarding the sandbox there are a few things I wanted to point out:

*As I mentioned in a previous comment above it is possible to append or override the Sandbox with a plugin. It would be possible to create a plugin that whitelisted everything automatically. It would not disable the sandbox but would make it allow everything. Creating this functionality as a separate plugin would be preferable to having it as part of the core functionality. This way users who want to disable the sandbox can actively do so but others aren't exposed to large security holes through misconfigurations. Can we get someone to volunteer to create such a plugin?

  • Lastly, Andrew Bayer (Andrew Bayer) presented the new Declarative Pipeline syntax at Jenkins World. This is installed with the pipeline-model-definition plugin. This plugin extends Pipeline to include a declarative syntax that does not allow imperative scripting but simplifies the construction of pipeline stages, notifications, docker images, etc to execute pipeline steps. Having end users build their Pipelines using the declarative model with no scripting also allows any syntax errors to be found during compilation, instead of runtime, and should not trigger any script security errors, any Groovy methods would be built into the step definitions themselves.

pwolf@cloudbees.com (JIRA)

unread,
Oct 4, 2016, 7:54:24 PM10/4/16
to jenkinsc...@googlegroups.com
Patrick Wolf edited a comment on Improvement JENKINS-28178
Regarding the sandbox there are a few things I wanted to point out:

* The built in whitelist (and blacklist) for Script Security is available in GitHub and can be updated via a Pull Request to add more signatures. This is a great way to add common, safe functions to the sandbox that benefits everyone:
** https://github.com/jenkinsci/script-security-plugin/tree/master/src/main/resources/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists
** https://issues.jenkins-ci.org/browse/JENKINS-25804

* If you create a Shared library at the Jenkins master level all functions in this library are assumed to be safe (users must have run_script access to create add these libraries) and will bypass the sandbox.
** https://github.com/jenkinsci/workflow-cps-global-lib-plugin


*As I mentioned in a previous comment above it is possible to append or override the Sandbox with a plugin. It would be possible to create a plugin that whitelisted everything automatically. It would not disable the sandbox but would make it allow everything. Creating this functionality as a separate plugin would be preferable to having it as part of the core functionality. This way users who want to disable the sandbox can actively do so but others aren't exposed to large security holes through misconfigurations. Can we get someone to volunteer to create such a plugin?
** https://issues.jenkins-ci.org/browse/JENKINS-28178?focusedCommentId=255040&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-255040

* Lastly, Andrew Bayer ([~abayer]) presented the new Declarative Pipeline syntax at Jenkins World. This is installed with the {{pipeline-model-definition}} plugin.  This plugin extends Pipeline to include a declarative syntax that does not allow imperative scripting but simplifies the construction of pipeline stages, notifications, docker images, etc to execute pipeline steps. Having end users build their Pipelines using the declarative model with no scripting also allows any syntax errors to be found during compilation, instead of runtime, and should not trigger any script security errors, any Groovy methods would be built into the step definitions themselves.

pwolf@cloudbees.com (JIRA)

unread,
Oct 4, 2016, 7:56:08 PM10/4/16
to jenkinsc...@googlegroups.com
Patrick Wolf edited a comment on Improvement JENKINS-28178
Regarding the sandbox there are a few things I wanted to point out:

* The built in whitelist (and blacklist) for Script Security is available in GitHub and can be updated via a Pull Request to add more signatures. This is a great way to add common, safe functions to the sandbox that benefits everyone:

* If you create a Shared library at the Jenkins master level all functions in this library are assumed to be safe (users must have run_script access to create add these libraries) and will bypass the sandbox.
** [Shared Libraries| https://github.com/jenkinsci/workflow-cps-global-lib-plugin ]

* As I mentioned in a previous comment above it is possible to append or override the Sandbox with a plugin. It would be possible to create a plugin that whitelisted everything automatically. It would not disable the sandbox but would make it allow everything. Creating this functionality as a separate plugin would be preferable to having it as part of the core functionality. This way users who want to disable the sandbox can actively do so but others aren't exposed to large security holes through misconfigurations. Can we get someone to volunteer to create such a plugin?
** [Comment| https://issues.jenkins-ci.org/browse/JENKINS-28178?focusedCommentId=255040&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-255040 ]

* Lastly, Andrew Bayer ([~abayer]) presented the new Declarative Pipeline syntax at Jenkins World. This is installed with the {{pipeline-model-definition}} plugin.  This plugin extends Pipeline to include a declarative syntax that does not allow imperative scripting but simplifies the construction of pipeline stages, notifications, docker images, etc to execute pipeline steps. Having end users build their Pipelines using the declarative model with no scripting also allows any syntax errors to be found during compilation, instead of runtime, and should not trigger any script security errors, any Groovy methods would be built into the step definitions themselves.

danny@kirchmeier.us (JIRA)

unread,
Oct 21, 2016, 1:52:06 AM10/21/16
to jenkinsc...@googlegroups.com

> It would be possible to create a plugin that whitelisted everything automatically. It would not disable the sandbox but would make it allow everything. Creating this functionality as a separate plugin would be preferable to having it as part of the core functionality. This way users who want to disable the sandbox can actively do so but others aren't exposed to large security holes through misconfigurations. Can we get someone to volunteer to create such a plugin?

It appears someone may have created such a plugin: https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+Security+Plugin
I haven't had a chance to try this plugin out for myself, but it looks promising.

danny@kirchmeier.us (JIRA)

unread,
Oct 21, 2016, 1:53:02 AM10/21/16
to jenkinsc...@googlegroups.com
Danny Kirchmeier edited a comment on Improvement JENKINS-28178
> {quote} It would be possible to create a plugin that whitelisted everything automatically. It would not disable the sandbox but would make it allow everything. Creating this functionality as a separate plugin would be preferable to having it as part of the core functionality. This way users who want to disable the sandbox can actively do so but others aren't exposed to large security holes through misconfigurations. Can we get someone to volunteer to create such a plugin? {quote}

It appears someone may have created such a plugin: https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+Security+Plugin
I haven't had a chance to try this plugin out for myself, but it looks promising.

jglick@cloudbees.com (JIRA)

unread,
Oct 21, 2016, 12:37:02 PM10/21/16
to jenkinsc...@googlegroups.com

Do not install that plugin unless as an admin you can verify that either all authenticated users are fully trusted, or there is no way anyone can either create jobs or edit Pipeline script. I really do not recommend it.

federicon@al.com.au (JIRA)

unread,
Feb 5, 2017, 7:36:02 PM2/5/17
to jenkinsc...@googlegroups.com
Federico Naum assigned an issue to Federico Naum
 
Change By: Federico Naum
Assignee: Jesse Glick Federico Naum

federicon@al.com.au (JIRA)

unread,
Feb 5, 2017, 8:04:02 PM2/5/17
to jenkinsc...@googlegroups.com
Federico Naum commented on Improvement JENKINS-28178
 
Re: Option to disable sandbox in CpsScmFlowDefinition

Just checking if the issue I'm seeing is the same as this one.

I have a _ global shared library_ (https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Shared+Groovy+Libraries+Plugin) setup that works fine, but when I try to run something from a branch using the Library@BranchName notation I get the {{ hudson.remoting.ProxyException: groovy.lang.MissingMethodException:}} exception

The thing is that I'm running the job with the admin user which has full permissions. Also, the exception is not logged in under In-process Script Approval so I can not whitelist it.

Is this another bug or is it the same? Do you need logs or something?

Since we do trust all the authenticated users and since we are using github enterprise as the backend for the global shared library, we have every branch created and every commit logged, so I gave the https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+SecuIrity+Plugin a try, but did not work.

If the configuration toggle is not going to be implemented, I think my next step is to recompile this plugin with the sandbox disable?

federicon@al.com.au (JIRA)

unread,
Feb 5, 2017, 8:06:03 PM2/5/17
to jenkinsc...@googlegroups.com
Federico Naum edited a comment on Improvement JENKINS-28178
Just checking if the issue I'm seeing is the same as this one.

I have a _   [ global shared library_ library|http://example.com] (https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Shared+Groovy+Libraries+Plugin ) ] setup that works fine, but when I try to run something from a branch using the _Library@BranchName_ notation I get the {{ hudson.remoting.ProxyException: groovy.lang.MissingMethodException:}} exception

The thing is that I'm running the job with the admin user which has full permissions.  Also, the exception is not logged in under *In-process Script Approval* so I can not whitelist it.


Is this another bug or is it the same? Do you need logs or something?

Since we do trust all the authenticated users and since we are using github enterprise as the backend for the global shared library, we have every branch created and every commit logged, so I gave the [permissive plugin script| https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+SecuIrity+Plugin ] a try, but did not work.

If the configuration toggle is not going to be implemented, I think my next step is to recompile this plugin with the sandbox disable?



federicon@al.com.au (JIRA)

unread,
Feb 5, 2017, 8:07:02 PM2/5/17
to jenkinsc...@googlegroups.com
Federico Naum edited a comment on Improvement JENKINS-28178
Just checking if the issue I'm seeing is the same as this one.

I have a  [ global shared library| http://example.com]( https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Shared+Groovy+Libraries+Plugin] setup that works fine, but when I try to run something from a branch using the _Library@BranchName_ notation I get the {{ hudson.remoting.ProxyException: groovy.lang.MissingMethodException:}} exception

The thing is that I'm running the job with the admin user which has full permissions.  Also, the exception is not logged in under *In-process Script Approval* so I can not whitelist it.

Is this another bug or is it the same? Do you need logs or something?

Since we do trust all the authenticated users and since we are using github enterprise as the backend for the global shared library, we have every branch created and every commit logged, so I gave the [permissive plugin script|https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+SecuIrity+Plugin] a try, but did not work.

If the configuration toggle is not going to be implemented, I think my next step is to recompile this plugin with the sandbox disable?



federicon@al.com.au (JIRA)

unread,
Feb 5, 2017, 11:37:07 PM2/5/17
to jenkinsc...@googlegroups.com
Federico Naum edited a comment on Improvement JENKINS-28178
Just checking if the issue I'm seeing is the same as this one.

I have a  [global shared library|https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Shared+Groovy+Libraries+Plugin] setup that works fine, but when I try to run something from a branch using the _Library ('library @ BranchName_ BranchName')_ notation I get the {{hudson.remoting.ProxyException: groovy.lang.MissingMethodException:}} exception

The thing is that I'm running the job with the admin user which has full permissions.  Also, the exception is not logged in under *In-process Script Approval* so I can not whitelist it.

Is this another bug or is it the same? Do you need logs or something?

Since we do trust all the authenticated users and since we are using github enterprise as the backend for the global shared library, we have every branch created and every commit logged, so I gave the [permissive plugin script|https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+SecuIrity+Plugin] a try, but did not work.

If the configuration toggle is not going to be implemented, I think my next step is to recompile this plugin with the sandbox disable?



federicon@al.com.au (JIRA)

unread,
Feb 5, 2017, 11:46:02 PM2/5/17
to jenkinsc...@googlegroups.com

Hi Sorry for the noise,
I got this working now. I re-read the documentation at https://jenkins.io/doc/book/pipeline/shared-libraries/ and found this piece of text which I think it was not there the first time I read it

For Shared Libraries which only define Global Variables (vars/), or a Jenkinsfile which only needs a Global Variable, the annotation pattern @Library('my-shared-library') _ may be useful for keeping code concise. In essence, instead of annotating an unnecessary import statement, the symbol _ is annotated.

Anyway, basically now (without using the permissive plugin script ) this is working using the notation

@Library('library@BranchName') _

instead of:

@Library('library@BranchName')
import foo

where foo is a file in {{ /var/foo.groovy}}

federicon@al.com.au (JIRA)

unread,
Feb 5, 2017, 11:47:02 PM2/5/17
to jenkinsc...@googlegroups.com
Federico Naum edited a comment on Improvement JENKINS-28178
Hi Sorry for the noise,
I got this working now. I re-read the documentation at https://jenkins.io/doc/book/pipeline/shared-libraries/ and found this piece of text which I think it was not there the first time I read it

??For Shared Libraries which only define Global Variables (vars/), or a Jenkinsfile which only needs a Global Variable, the annotation pattern @Library('my-shared-library') _ may be useful for keeping code concise. In essence, instead of annotating an unnecessary import statement, the symbol _ is annotated.??


Anyway, basically now (without using the [permissive plugin script|https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+SecuIrity+Plugin] ) this is working using the notation

*@Library('library@BranchName') \_*

instead of:

*@Library('library@BranchName')*
*import foo*

where {{foo}} is a file in {{ * /var/foo.groovy }} *





federicon@al.com.au (JIRA)

unread,
Feb 5, 2017, 11:49:02 PM2/5/17
to jenkinsc...@googlegroups.com
Federico Naum edited a comment on Improvement JENKINS-28178
Hi Sorry for the noise,
I got this working now. I re-read the documentation at https://jenkins.io/doc/book/pipeline/shared-libraries/ and found this piece of text which I think it was not there the first time I read it

??For Shared Libraries which only define Global Variables (vars/), or a Jenkinsfile which only needs a Global Variable, the annotation pattern @Library('my-shared-library') _ may be useful for keeping code concise. In essence, instead of annotating an unnecessary import statement, the symbol _ is annotated.??


Anyway, basically now (without using the [permissive plugin script|https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+SecuIrity+Plugin] ) this is working using the notation by switching


*@Library('library@BranchName') \_ *
instead of:

 * @Library('library@BranchName')*
* import foo*

where {{foo}} is a file in */var/foo.groovy*

 with the following notation:

*@Library('library@BranchName') \_*

I bit anti-intuitive for me, but hey.. I'm happy that this is working

jglick@cloudbees.com (JIRA)

unread,
Feb 15, 2017, 2:23:03 PM2/15/17
to jenkinsc...@googlegroups.com
Jesse Glick assigned an issue to Unassigned
 
Change By: Jesse Glick
Assignee: Federico Naum

p.rogovoy@gmail.com (JIRA)

unread,
May 28, 2018, 7:29:02 AM5/28/18
to jenkinsc...@googlegroups.com
Pavel Rogovoy commented on Improvement JENKINS-28178
 
Re: Option to disable sandbox in CpsScmFlowDefinition

+1 for adding a feature to turn off the script security altogether. I spend a lot of time fighting with this even though everyone is admin on the team. "Permisssive Script Security" plugin is not the best solution as it doesn't work for us! I think this feature must be disabled altogether as it performs very awful as for today.
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

p.rogovoy@gmail.com (JIRA)

unread,
May 28, 2018, 7:30:13 AM5/28/18
to jenkinsc...@googlegroups.com
Pavel Rogovoy updated an issue
 
Jenkins / Bug JENKINS-28178
Change By: Pavel Rogovoy
Issue Type: Improvement Bug

p.rogovoy@gmail.com (JIRA)

unread,
May 28, 2018, 7:30:14 AM5/28/18
to jenkinsc...@googlegroups.com
Pavel Rogovoy updated an issue
Change By: Pavel Rogovoy
Priority: Major Critical

p.rogovoy@gmail.com (JIRA)

unread,
May 28, 2018, 7:40:05 AM5/28/18
to jenkinsc...@googlegroups.com
Pavel Rogovoy updated an issue
Change By: Pavel Rogovoy
Priority: Critical Blocker

p.rogovoy@gmail.com (JIRA)

unread,
May 28, 2018, 7:41:04 AM5/28/18
to jenkinsc...@googlegroups.com
Pavel Rogovoy updated an issue
Change By: Pavel Rogovoy
Priority: Blocker Critical

jonas.l.jonsson@ericsson.com (JIRA)

unread,
May 29, 2018, 3:58:03 AM5/29/18
to jenkinsc...@googlegroups.com
Jonas Jonsson commented on Bug JENKINS-28178
 
Re: Option to disable sandbox in CpsScmFlowDefinition

As a Jenkins-admin with quite a few system groovy scripts, I would like to white-list certain paths (that contains my version controlled scripts) as 100% secure, so that I (once the change has been submitted) can use the latest and most up-to-date version of my script immediately. 

May it be pipelines or groovy system scripts, if the Jenkins-admin approve the scripts (before they're executed), they should be allowed to run.

jglick@cloudbees.com (JIRA)

unread,
Jun 5, 2018, 6:48:18 PM6/5/18
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
 
Jenkins / New Feature JENKINS-28178

Better to use trusted libraries.
Change By: Jesse Glick
Issue Type: Bug New Feature

mattvonrocketstein@gmail.com (JIRA)

unread,
Sep 25, 2019, 5:46:17 PM9/25/19
to jenkinsc...@googlegroups.com
matt matthews edited a comment on New Feature JENKINS-28178
 
Re: Option to disable sandbox in CpsScmFlowDefinition
Suggestign Suggesting to just use shared/trusted libraries is not enough IMHO, we need a switch to turn this stuff off.  as an example, today I have a basic Jenkinsfile that's throwing errors with [].tail():
Scripts not permitted to use staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods tail java.lang.Object[].
Job console offers a link to go to the ScriptApproval URL to approve, but then it does not remember the approval.. I return to the job generating the error and then it happens again in exactly the same way, telling me to approve.  There's nothing further I can even do here to debug that problem (which is just another distraction from the work I really want to do), so I get forced into rewrite `[].tail()` as different-but-equivalent groovy, something with `[].findAll{}`, which just works. 

So why is Jenkins not remembering the approvals?  Why is `findAll` safer than `tail`?  Why does this plugin exist in the ecosystem if it doesn't work and can't work? [https://wiki.jenkins.io/display/JENKINS/Permissive+Script+Security+Plugin]

Like other users, our Jenkins is behind a VPN, and we have multiple Jenkins instances so that we don't have to deal with all the complexity of highly granular user/job/credential permissioning.  Since all people who can login to a given instance are admins on that instance.. our experience is that none of script-security stuff adds security, it just degrades our stability.

Please, can we just get a config option to just turn this off everywhere?
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

mattvonrocketstein@gmail.com (JIRA)

unread,
Sep 25, 2019, 5:46:17 PM9/25/19
to jenkinsc...@googlegroups.com

Suggestign to just use shared/trusted libraries is not enough IMHO, we need a switch to turn this stuff off.  as an example, today I have a basic Jenkinsfile that's throwing errors with [].tail():

mattvonrocketstein@gmail.com (JIRA)

unread,
Sep 25, 2019, 6:03:13 PM9/25/19
to jenkinsc...@googlegroups.com
matt matthews edited a comment on New Feature JENKINS-28178
Suggesting to just use shared/trusted libraries is not enough IMHO, we need a switch to turn this stuff off.  as an example, today I have a basic Jenkinsfile that's throwing errors with [].tail():

christoph.henrici@chesnb.com (JIRA)

unread,
Sep 28, 2019, 5:22:04 AM9/28/19
to jenkinsc...@googlegroups.com

Second   matt matthews

fnasser@redhat.com (JIRA)

unread,
Feb 10, 2020, 4:46:04 PM2/10/20
to jenkinsc...@googlegroups.com

Third that.
Reply all
Reply to author
Forward
0 new messages