@Whitelist pipeline from multibranch project or allow out of sandbox

[Guybrush Threepwood]

hello I have a Jenkins fileas part of a multibranch pipeline But I'm getting seccurityissues when trying to create a directory inside the workspace how can either disable the sandbox for this pipeline or whitelist the methods I need to use from my code

Thanks.

This is the code:

============================================================

import java.io.File;
import java.io.IOException;
import org.apache.commons.io.FileUtils;

//autocancelled = false
node ('AnsibleBuild') {
        try {
        checkout scm
        def versions = readJSON file: 'versions.json'
                stage('Getting Python source Code') {
                        echo " before del try"
                                try {
                                        echo "inside try";
                                        File f = new File("python");
                                        echo "after new file";
                                        //FileUtils.cleanDirectory(f); //clean out directory (this is optional -- but good know)
                                        FileUtils.forceDelete(f); //delete directory
                                        //FileUtils.forceMkdir(f); //create directory
                                }
                                catch (IOException e) {
                                        echo "pinazo cleaning python"
                                        echo e.getStackTrace();
                                } // catch delete dir
                         echo "Despues del try"
                         sh 'pwd'
                         sh 'ls -la'
                         sh 'mkdir python'
                                dir("python") {
                                        echo 'Downloading Python code from: https://www.python.org/ftp/python/3.7.2/Python-3.7.2.tgz'
                                        sh 'curl https://www.python.org/ftp/python/3.7.2/Python-3.7.2.tgz -o Python-3.7.2.tgz'
                                        sh 'file Python-3.7.2.tgz' // needs to be checked that we downloaded a tgz file
                                        sh 'tar -xzvf Python-3.7.2.tgz'
                                } //dir python
                } // stage
        currentBuild.result = 'SUCCESS'
        } //try node
        catch (e) {
                echo "General Fostion";
                echo "trace General" + e.getStackTrace();
                currentBuild.result = 'FAILURE'
        } //end catch
try {
  echo "Cleaning WS"
  dir(python) {
        deleteDir()
        }
} //try clena WS
catch (e) {
        echo "Error Cleaning WS";
        echo "trace cleaning" + e.getStackTrace();
        currentBuild.result = 'FAILURE'
} //catch clena WS
} //node
========================================================

And I'm getting error: for line 14

trace General[org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectNew(StaticWhitelist.java:184), org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:170), org.kohsuke.groovy.sandbox.impl.Checker$3.call(Checker.java:197), org.kohsuke.groovy.sandbox.impl.Checker.checkedConstructor(Checker.java:202), com.cloudbees.groovy.cps.sandbox.SandboxInvoker.constructorCall(SandboxInvoker.java:21), WorkflowScript.run(WorkflowScript:14), ___cps.transform___(Native Method), com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:96), com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82), sun.reflect.GeneratedMethodAccessor148.invoke(Unknown Source), sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43), java.lang.reflect.Method.invoke(Method.java:498), com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72), com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21), com.cloudbees.groovy.cps.Next.step(Next.java:83), com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174), com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163), org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129), org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268), com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163), org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$101(SandboxContinuable.java:34), org.jenkinsci.plugins.workflow.cps.SandboxContinuable.lambda$run0$0(SandboxContinuable.java:59), org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:136), org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:58), org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:182), org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:332), org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:83), org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:244), org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:232), org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64), java.util.concurrent.FutureTask.run(FutureTask.java:266), hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131), jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28), jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59), java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511), java.util.concurrent.FutureTask.run(FutureTask.java:266), java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149), java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624), java.lang.Thread.run(Thread.java:748)]

Any ideas how to fix this. what is the right way of targeting this kind of issue?

Thanks.

[Jan Monterrubio]

There’s an admin view for white listing method calls. If you don’t have admin access you can’t see it. 

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ec75388f-8a03-424f-a9ca-43fd1d9ba452%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Waite]

I don't think it is safe to whitelist the java File object or its methods.

Is there a reason you're not relying on the ability of the dir step to create a directory if one does not exist?  Refer to https://stackoverflow.com/questions/42654875/jenkins-pipeline-create-directory for the stackoverflow comments.

I wrote the following small test that seems to create a directory, add contents, then remove the directory, using the DSL rather than using java File methods.

node('!windows') {

    echo 'entering'

    sh 'ls -alrR'

    echo 'deleting contents'

    deleteDir()

    echo 'after content delete'

    sh 'ls -alrR'

    dir('some-dir') {

       sh 'date >> datefile'

    }

    echo 'after content create'

    sh 'ls -alrR'

}

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CADgiF9JDdznaJaQ3wP%2BRA8_YXRcc%3DMq_JtXNU6R56OBUKSFaLg%40mail.gmail.com.

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

--

Thanks!

Mark Waite

[Guybrush Threepwood]

Thank you for your answer,

I will try that Actually I'm not trying to only delete the directory but to create/clean it up.

I was using the File just beacuseI might have landed to the wrong google page :-)

I'm verry new to Jenkins and pipelines and I always want to do complicated things.

I agree that whitelisting all the methods probably is not a good Idea.

And that leads me to two questions.

Why a person is not allowed to do anything in his workspace?

     is the workspace shared by several executions or it is created each time a pipeline is executed.

Why there is no sandbox check for multibranch pipelines as it is for regular ones.

In this case yes I am the Jenkins admin and I know that multi-Branch pipeline where is it conected to.

So if I have the control of the code It would be nice to allow it to run I mean I might want to create some admin utilities an put them there

knowing that they will only run because they are on that multi branch pipeline that I can control and users still can not execute nasty things.

Thank you.

Thoughts to my two intriguing questions are wellcome.

[Mark Waite]

On Thu, Mar 21, 2019 at 3:01 AM Guybrush Threepwood <guybr...@gmail.com> wrote:

Thank you for your answer,

I will try that Actually I'm not trying to only delete the directory but to create/clean it up.

I was using the File just beacuseI might have landed to the wrong google page :-)

I'm verry new to Jenkins and pipelines and I always want to do complicated things.

I just realized that your use of the File object hints at a larger misunderstanding about Jenkins Pipeline and where things execute.  Sorry that I didn't detect that sooner.

Java and groovy logic inside the Pipeline (like your File() call) executes on the Jenkins master.  Loops, conditionals, and assignments are executed on the master.  Steps (like dir, deleteDir, checkout) execute where the implementation of the specific step defines them to execute.   For example, the dir, deleteDir, and checkout steps all execute on the agent, while the stash and unstash steps execute on both the agent and the master. 

Thus, your use of the File() call was attempting to create a file on the master, not on the agent or in the workspace like you hoped it would.

The general guiding principle is to place as much of the pipeline work as possible inside scripts that are called by the sh step or the bat step or the powershell step.  The more work that you place in the Pipeline script, the more likely you are to place undue load on your master that would be better placed on an agent.  Adding more agents for additional capacity is easy.  Adding more compute capacity to a master is more difficult.

Refer to the free Jenkins Pipeline Fundamentals class from CloudBees for more information.  CloudBees also hosts a Pipeline Tips from the Pros webinar that specifically notes the importance of keeping Pipeline code as simple as possible, with as much work done in your own build scripts as you can. 

 

I agree that whitelisting all the methods probably is not a good Idea.

And that leads me to two questions.

Why a person is not allowed to do anything in his workspace?

     is the workspace shared by several executions or it is created each time a pipeline is executed.

The workspace is used for a single execution.  If it does not exist, it is created.  If it exists and is not in use, it is reused.  If an existing workspace is already in use, then a new workspace is created for a new build.

 

Why there is no sandbox check for multibranch pipelines as it is for regular ones.

I don't understand the question.  Can you provide more detail?

 

In this case yes I am the Jenkins admin and I know that multi-Branch pipeline where is it conected to.

So if I have the control of the code It would be nice to allow it to run I mean I might want to create some admin utilities an put them there

knowing that they will only run because they are on that multi branch pipeline that I can control and users still can not execute nasty things.

You may find the blog post from Tyler Croy helpful - https://brokenco.de/2017/08/03/donut-disable-groovy-sandbox.html

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/1bb8fc53-c418-4d7e-994c-97b96b727ba4%40googlegroups.com.

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

--

Thanks!

Mark Waite

[Guybrush Threepwood]

OMG!!!

Thank your verry much for your answer.

I definitelly need to go back to the pipelines fundamentals training looks like I missed a lot there.

The general guiding principle is to place as much of the pipeline work as possible inside scripts that are called by the sh step or the bat step or the powershell step.  The more work that you place in the Pipeline script, the more likely you are to place undue load on your master that would be better placed on an agent.  Adding more agents for additional capacity is easy.  Adding more compute capacity to a master is more difficult.

That sounds like verry sensible piece of advice I need to think over that. as I was thinking on creating complex groovy pipelines for the logic of process not in doing shell scripts. althoughtI want the  agents to do the work ofcourse.

Regarding the sandbox

When you have single pipeline with inline code you have a checkbox to disable sandbox.

But as soon as you select get the source code from SCM the checkbox is gone and I guess we are sandboxed again.

That check box is also gone on multibranch projects since they always are from SCM sources.

it will be nice giving the fact that I know that the SCM is reliable and secure to be able to generate pipelines out of the sandbox. (for admin purposes)

If we can not get out of the sandbox in pipelines from scm what would be the right approach to automate things like.

create automatically new simple pipelines (with code on scm)

or create new roles

or grant roles to users.

automatically.

I have to automate those things and I was thinking on having a pipeline that could be called via api to do the job for me.

I do not know if creating libraries is the right place for that. since I guess any one can call libraries from their pipelines and I do not want that.

Thank you verry much for your clarifications.

Sorry for asking silly questions but I'm forced to learn verry fast about this.

[Mark Waite]

On Thu, Mar 21, 2019 at 12:20 PM Guybrush Threepwood <guybr...@gmail.com> wrote:

OMG!!!

Thank your verry much for your answer.

I definitelly need to go back to the pipelines fundamentals training looks like I missed a lot there.

The general guiding principle is to place as much of the pipeline work as possible inside scripts that are called by the sh step or the bat step or the powershell step.  The more work that you place in the Pipeline script, the more likely you are to place undue load on your master that would be better placed on an agent.  Adding more agents for additional capacity is easy.  Adding more compute capacity to a master is more difficult.

That sounds like verry sensible piece of advice I need to think over that. as I was thinking on creating complex groovy pipelines for the logic of process not in doing shell scripts. althoughtI want the  agents to do the work ofcourse.

Regarding the sandbox

When you have single pipeline with inline code you have a checkbox to disable sandbox.

But as soon as you select get the source code from SCM the checkbox is gone and I guess we are sandboxed again.

That check box is also gone on multibranch projects since they always are from SCM sources.

it will be nice giving the fact that I know that the SCM is reliable and secure to be able to generate pipelines out of the sandbox. (for admin purposes)

If we can not get out of the sandbox in pipelines from scm what would be the right approach to automate things like.

create automatically new simple pipelines (with code on scm)

or create new roles

or grant roles to users.

automatically.

Those seem like the types of tasks you might want to do with system groovy script or with the Jenkins command line interface.  They seem to be "system level" operations that are changing the configuration of the Jenkins server, rather than specific jobs.

Pipeline is a domain specific language based on groovy which is used in the Jenkinsfile of Pipeline jobs.  System groovy script is not run from Pipeline jobs, but rather is executed at startup or from the system groovy console.  Refer to https://wiki.jenkins.io/display/JENKINS/Jenkins+Script+Console for more information on system groovy script.

Mark Waite

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/2a5ae31c-4f46-418c-b359-15279142e45e%40googlegroups.com.

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

--

Thanks!

Mark Waite