On Thu, Mar 21, 2019 at 3:01 AM Guybrush Threepwood <guybrush...@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
<https://standard.cbu.cloudbees.com/cloudbees-university-jenkins-pipeline-fundamentals>
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


>
> Thank you.
> Thoughts to my two intriguing questions are wellcome.
>
>
>
> El jueves, 21 de marzo de 2019, 5:31:24 (UTC+1), Mark Waite escribió:
>>
>> 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'
>> }
>>
>> On Wed, Mar 20, 2019 at 8:24 PM Jan Monterrubio <janmont...@gmail.com>
>> wrote:
>>
>>> There’s an admin view for white listing method calls. If you don’t have
>>> admin access you can’t see it.
>>>
>>> On Wed, Mar 20, 2019 at 14:03 Guybrush Threepwood <guybr...@gmail.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>> --
>>>> 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
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/ec75388f-8a03-424f-a9ca-43fd1d9ba452%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> 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/CADgiF9JDdznaJaQ3wP%2BRA8_YXRcc%3DMq_JtXNU6R56OBUKSFaLg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/CADgiF9JDdznaJaQ3wP%2BRA8_YXRcc%3DMq_JtXNU6R56OBUKSFaLg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
> --
> 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-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/1bb8fc53-c418-4d7e-994c-97b96b727ba4%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/1bb8fc53-c418-4d7e-994c-97b96b727ba4%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFEk%3DCquZne65Wc8EQje_a9dHObzefLQTinhL%3D-6uX9MA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to