Pipeline Shared Groovy Libraries and system groovy script classpath

[Andreas Mandel]

Hi List,

since the last security updates, a common practice to work with system groovy scripting does not work any more. It might be easily resolvable with a small(?) change in the Pipeline Shared Groovy Libraries plugin.

We have a lot of system groovy scripts in Jenkins jobs that take care for cleanup, monitoring, etc. These jobs check out certain scripts from SCM and then call them as a system groovy script. With the recent changes, you cannot simply add and call something "dynamic" in the workspace as system groovy script anymore. I do not want to go a step back and put the whole code inside the Jenkins job definition.

On the other hand with the Pipeline Shared Groovy Libraries plugin we now have a quite powerful library management plugin for groovy libraries. Unfortunately as of now this only works for pipeline jobs and not for the use in system groovy scripts.

Would it be possible to add a functionality to mark a library in the Pipeline Shared Groovy Libraries plugin as "system groovy library" and so make it available on the class path of any system groovy script?

Could this work out? How are other resolving this topic?


Thanks,
Kind Regards,
Andreas.

[Bruno P. Kinoshita]

+1 Andreas


Wanting the same right now. Started a small sandbox [1] some time ago to try understand everything I would need for active-choices, but got distracted by security and performance issues.

* Execute a Groovy script
* Allow user to add extra jars
* Graple dependency management support
* Option to enable script-security integration (on by default)

The Groovy execution layer in active-choices came from dynamicparameter-plugin, then was a bit tweaked. Later we added script-security. Now need to look into extra jars (right now integrating ImageJ).

Cheers
Bruno
[1] https://github.com/kinow/groovy-script-lib

________________________________
From: Andreas Mandel <andreas...@gmail.com>
To: Jenkins Developers <jenkin...@googlegroups.com>
Sent: Sunday, 7 May 2017 10:14 PM
Subject: Pipeline Shared Groovy Libraries and system groovy script classpath

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c3537dfe-c206-428d-9e3a-7a298d98a785%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Sandell]

I'm not really sure what you are asking here, how did you call these scripts before?

A Pipeline Shared Groovy Librariy that is trusted is able to call any Jenkins api since it is not running in the sandbox, although still running in CPS, but should still be able to call for example RemotingDiagnostics.executeGroovy even though it is a biig security risk to do so.

The scriptler plugin has a library feature iirc that can also be run as a build step.

/B

On Sun, May 7, 2017 at 3:09 PM, 'Bruno P. Kinoshita' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

+1 Andreas


Wanting the same right now. Started a small sandbox [1] some time ago to try understand everything I would need for active-choices, but got distracted by security and performance issues.

* Execute a Groovy script
* Allow user to add extra jars
* Graple dependency management support
* Option to enable script-security integration (on by default)

The Groovy execution layer in active-choices came from dynamicparameter-plugin, then was a bit tweaked. Later we added script-security. Now need to look into extra jars (right now integrating ImageJ).

Cheers
Bruno
[1] https://github.com/kinow/groovy-script-lib

________________________________
From: Andreas Mandel <andreas...@gmail.com>

To: Jenkins Developers <jenkinsci-dev@googlegroups.com>

Sent: Sunday, 7 May 2017 10:14 PM
Subject: Pipeline Shared Groovy Libraries and system groovy script classpath

Hi List,

since the last security updates, a common practice to work with system groovy scripting does not work any more. It might be easily resolvable with a small(?) change in the Pipeline Shared Groovy Libraries plugin.

We have a lot of system groovy scripts in Jenkins jobs that take care for cleanup, monitoring, etc. These jobs check out certain scripts from SCM and then call them as a system groovy script. With the recent changes, you cannot simply add and call something "dynamic" in the workspace as system groovy script anymore. I do not want to go a step back and put the whole code inside the Jenkins job definition.

On the other hand with the Pipeline Shared Groovy Libraries plugin we now have a quite powerful library management plugin for groovy libraries. Unfortunately as of now this only works for pipeline jobs and not for the use in system groovy scripts.

Would it be possible to add a functionality to mark a library in the Pipeline Shared Groovy Libraries plugin as "system groovy library" and so make it available on the class path of any system groovy script?

Could this work out? How are other resolving this topic?


Thanks,
Kind Regards,
Andreas.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c3537dfe-c206-428d-9e3a-7a298d98a785%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/800881429.5606274.1494162579878%40mail.yahoo.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Andreas Mandel]

Hello Robert,

thanks for the feedback.

I try to be more concrete. We have a collection of maintenance system groovy scripts, which we have stored in a git repository. One of the scripts for example purges orphan or old workspaces. We then have a time triggered Jenkins Job that fetches the script from git and calls it via "Execute System Groovy Script" Build step and for example "jenkins/PurgeWorkspace.groovy" as script file from just fetched workspace.

These scripts are now not trusted by default any more they require the security settings to be opened up, for example to get around "Scripts not permitted to use staticMethod hudson.model.Hudson getInstance". Also, if the script is more complex and the classpath needs to be extended (to point somewhere in the workspace) this does not seem to be possible at all. This was done via the "Classpath" option in the System Groovy build step before.

This leads to my proposal to be able to mark one or several of the Pipeline Shared Groovy Libraries as "Places on trusted system classpath" to be able to put our scripts in such a library and being able to call them again in a Jenkins Job. I did not use the Scriptler Plugin yet. Seeing that it was not updated for more than a year now makes me a bit reluctant in testing it out. For some reason I can not find it in the update center?

Might be, there is a different solution?

Kind Regards,
Andreas.

Am Montag, 8. Mai 2017 12:43:39 UTC+2 schrieb Robert Sandell:

I'm not really sure what you are asking here, how did you call these scripts before?

A Pipeline Shared Groovy Librariy that is trusted is able to call any Jenkins api since it is not running in the sandbox, although still running in CPS, but should still be able to call for example RemotingDiagnostics.executeGroovy even though it is a biig security risk to do so.

The scriptler plugin has a library feature iirc that can also be run as a build step.

/B

On Sun, May 7, 2017 at 3:09 PM, 'Bruno P. Kinoshita' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

+1 Andreas


Wanting the same right now. Started a small sandbox [1] some time ago to try understand everything I would need for active-choices, but got distracted by security and performance issues.

* Execute a Groovy script
* Allow user to add extra jars
* Graple dependency management support
* Option to enable script-security integration (on by default)

The Groovy execution layer in active-choices came from dynamicparameter-plugin, then was a bit tweaked. Later we added script-security. Now need to look into extra jars (right now integrating ImageJ).

Cheers
Bruno
[1] https://github.com/kinow/groovy-script-lib

________________________________
From: Andreas Mandel <andreas...@gmail.com>

To: Jenkins Developers <jenkin...@googlegroups.com>

Sent: Sunday, 7 May 2017 10:14 PM
Subject: Pipeline Shared Groovy Libraries and system groovy script classpath

Hi List,

since the last security updates, a common practice to work with system groovy scripting does not work any more. It might be easily resolvable with a small(?) change in the Pipeline Shared Groovy Libraries plugin.

We have a lot of system groovy scripts in Jenkins jobs that take care for cleanup, monitoring, etc. These jobs check out certain scripts from SCM and then call them as a system groovy script. With the recent changes, you cannot simply add and call something "dynamic" in the workspace as system groovy script anymore. I do not want to go a step back and put the whole code inside the Jenkins job definition.

On the other hand with the Pipeline Shared Groovy Libraries plugin we now have a quite powerful library management plugin for groovy libraries. Unfortunately as of now this only works for pipeline jobs and not for the use in system groovy scripts.

Would it be possible to add a functionality to mark a library in the Pipeline Shared Groovy Libraries plugin as "system groovy library" and so make it available on the class path of any system groovy script?

Could this work out? How are other resolving this topic?


Thanks,
Kind Regards,
Andreas.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c3537dfe-c206-428d-9e3a-7a298d98a785%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/800881429.5606274.1494162579878%40mail.yahoo.com.

For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Mon, May 8, 2017 at 9:07 AM, Andreas Mandel <andreas...@gmail.com> wrote:
> I did not use the Scriptler Plugin yet. Seeing that it was not
> updated for more than a year now makes me a bit reluctant in testing it out.
> For some reason I can not find it in the update center?

Outstanding unresolved security issues.

[Andreas Mandel]

Hi Jesse,

thanks for pointing this out - I assume the same is for the Pipeline Classpath Step Plugin. It looks like I try to achieve something that you try to block out for security reasons.

Basically I need to be able to add something (dynamic) to the classpath of a system groovy script inside a Jenkins job for maintenance scripts to function. 

Kind regards, Andreas.

[Daniel Beck]

> On 09.05.2017, at 08:30, Andreas Mandel <andreas...@gmail.com> wrote:
>
> Pipeline Classpath Step Plugin

FYI:
https://jenkins.io/security/advisory/2017-03-20/#pipeline-classpath-step-plugin-allowed-script-security-sandbox-bypass

[Jesse Glick]

On Tue, May 9, 2017 at 2:30 AM, Andreas Mandel <andreas...@gmail.com> wrote:
> Basically I need to be able to add something (dynamic) to the classpath of a
> system groovy script inside a Jenkins job for maintenance scripts to
> function.

Scriptler would be the place to do this, if a maintainer steps up to
fix the security holes.

[Andreas Mandel]

Hi Jesse,

unfortunately this does not seem to be possible. From what I see, I cannot put anything (e.G. groovy classes) additional to the classpath for the script. I would prefer to store the scripts in a hosted git repository like with the Pipeline Shared Groovy Libraries.

My suggestion from the post with which I started the thread can not be easily realized or is out of scope?

Kind Regards, Andreas.

[Jesse Glick]

On Tue, May 9, 2017 at 11:54 AM, Andreas Mandel
<andreas...@gmail.com> wrote:
> From what I see, I cannot
> put anything (e.G. groovy classes) additional to the classpath for the
> script.

Would be an RFE for Scriptler I guess.

> My suggestion from the post with which I started the thread can not be
> easily realized or is out of scope?

Out of scope.

[Andreas Mandel]

I understand this - thanks!

Kind Regards, Andreas.