Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-49919

filename="../../../target/" will cause plugin to try to write outside its allowed directories.

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • cobertura-plugin
    • None
    • Jenkins ver. 2.89.4
      Cobertura Plugin 1.12

      We have some projects with unittests of java-script-code which generate a funny looking coverage.xml.

      It looks like:

      <?xml version="1.0" ?>
      <!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-04.dtd">
      <coverage lines-valid="38720"  lines-covered="13942"  line-rate="0.3601"  branches-valid="12524"  branches-covered="2516"  branch-rate="0.2009"  timestamp="1520251922363" complexity="0" version="0.1">
      <sources>
      	<source>/home/system/jenkins/workspace/master/gui/gui/src/main/scripts</source>
      </sources>
      <packages>
      	<package name="common"  line-rate="0.1429"  branch-rate="0" >
      	<classes>
      		<class name="common-modules.js"  filename="../../../target/jscoverage-files/common/common-modules.js"  line-rate="0.07690000000000001"  branch-rate="0" >
      		<methods>
      
      ...

       

      That wil cause:

      [Cobertura] Cobertura coverage report found.
      
      ERROR: Build step failed with exception
      Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to channel
      		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1693)
      		at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
      		at hudson.remoting.Channel.call(Channel.java:908)
      		at hudson.FilePath.act(FilePath.java:986)
      		at hudson.FilePath.act(FilePath.java:975)
      		at hudson.FilePath.mkdirs(FilePath.java:1158)
      		at hudson.plugins.cobertura.renderers.SourceCodePainter.paintSourceCode(SourceCodePainter.java:63)
      		at hudson.plugins.cobertura.renderers.SourceCodePainter.invoke(SourceCodePainter.java:137)
      		at hudson.plugins.cobertura.renderers.SourceCodePainter.invoke(SourceCodePainter.java:31)
      		at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2760)
      		at hudson.remoting.UserRequest.perform(UserRequest.java:207)
      		at hudson.remoting.UserRequest.perform(UserRequest.java:53)
      		at hudson.remoting.Request$2.run(Request.java:358)
      		at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to ladok3-build-08
      		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1693)
      		at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
      		at hudson.remoting.Channel.call(Channel.java:908)
      		at hudson.FilePath.act(FilePath.java:986)
      		at hudson.FilePath.act(FilePath.java:975)
      		at hudson.plugins.cobertura.CoberturaPublisher.perform(CoberturaPublisher.java:616)
      		at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
      		at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      		at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
      		at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)
      		at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1073)
      		at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)
      		at hudson.model.Run.execute(Run.java:1749)
      		at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
      		at hudson.model.ResourceController.execute(ResourceController.java:97)
      		at hudson.model.Executor.run(Executor.java:429)
      java.lang.SecurityException: agent may not mkdirs /var/lib/jenkins/jobs/master/target/jscoverage-files/xxx
      See https://jenkins.io/redirect/security-144 for more details
      	at jenkins.SoloFilePathFilter.noFalse(SoloFilePathFilter.java:31)
      	at jenkins.SoloFilePathFilter.mkdirs(SoloFilePathFilter.java:52)
      	at hudson.FilePath.mkdirs(FilePath.java:2939)
      	at hudson.FilePath.access$800(FilePath.java:196)
      	at hudson.FilePath$13.invoke(FilePath.java:1161)
      	at hudson.FilePath$13.invoke(FilePath.java:1158)
      	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2760)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:207)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:53)
      	at hudson.remoting.Request$2.run(Request.java:358)
      	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      	at org.jenkinsci.remoting.CallableDecorator.call(CallableDecorator.java:19)
      	at hudson.remoting.CallableDecoratorList$1.call(CallableDecoratorList.java:21)
      	at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
      	at java.lang.Thread.run(Thread.java:748)
      Build step 'Publish Cobertura Coverage Report' marked build as failure
      

       

      Somewhere along the way the cobertura parser gets confused and tries to write the files on the master in the wrong place, but gets stopped by the security framework.

          [JENKINS-49919] filename="../../../target/" will cause plugin to try to write outside its allowed directories.

          Jeff Pearce added a comment -

          Do you know what the path ../../../target/jscoverage-files/common/common-modules.js is relative to? It's expecting it to be relative to the folder the report is in, so if you remove the report it would be wrong.=

          I suspect I could make it so publishing coverage won't fail if this happens, but it would be even better if it could find the file so it's available in the coverage report

          Jeff Pearce added a comment - Do you know what the path ../../../target/jscoverage-files/common/common-modules.js is relative to? It's expecting it to be relative to the folder the report is in, so if you remove the report it would be wrong.= I suspect I could make it so publishing coverage won't fail if this happens, but it would be even better if it could find the file so it's available in the coverage report

          Anton Lundin added a comment -

          It is relative to the report, which is in target/jscoverage

          Anton Lundin added a comment - It is relative to the report, which is in target/jscoverage

          Jeff Pearce added a comment -

          Ah, well that seems easy enough. I should be able to repro and fix. BTW - what tool are you using to generate the coverage report?

          Jeff Pearce added a comment - Ah, well that seems easy enough. I should be able to repro and fix. BTW - what tool are you using to generate the coverage report?

          Anton Lundin added a comment -

          karma / jasmine.

          Anton Lundin added a comment - karma / jasmine.

          Kai Henzler added a comment -

          I'm running into the exact same problem when using karma/jasmine

          Kai Henzler added a comment - I'm running into the exact same problem when using karma/jasmine

            jeffpearce Jeff Pearce
            glance Anton Lundin
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: