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

glance+jenkins@acc.umu.se (JIRA)

unread,

Mar 5, 2018, 7:55:04 AM3/5/18

to jenkinsc...@googlegroups.com

Anton Lundin created an issue

Jenkins /

JENKINS-49919

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

Issue Type:	Bug
Assignee:	Unassigned
Components:	cobertura-plugin
Created:	2018-03-05 12:54
Environment:	Jenkins ver. 2.89.4 Cobertura Plugin 1.12
Priority:	Minor
Reporter:	Anton Lundin

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.

Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

jxpearce@godaddy.com (JIRA)

unread,

Jun 11, 2018, 5:59:02 PM6/11/18

to jenkinsc...@googlegroups.com

Jeff Pearce commented on

JENKINS-49919

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

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