Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: copyartifact-plugin, core
-
Labels:None
-
Environment:Jenkins 2.121.1, copyartifact plugin 1.40, Ubuntu 14.04 slave, Oracle JDK 1.8.0_171-b11
-
Similar Issues:
Description
We have a job that creates and archives a python virtual environment, which includes multiple symbolic links. For example:
lrwxrwxrwx 1 jenkins jenkins 30 Jun 27 17:40 UserDict.py -> /usr/lib/python2.7/UserDict.py
The downstream job then tries to copy the artifacts from the upstream job, but fails as follows:
java.io.FileNotFoundException: /var/lib/jenkins/jobs/.../builds/384/archive/venv/lib/python2.7/UserDict.py
at jenkins.util.VirtualFile$FileVF.open(VirtualFile.java:454)
at hudson.plugins.copyartifact.CopyArtifact.copyOne(CopyArtifact.java:614)
Caused: java.io.IOException: Failed to copy file:/var/lib/jenkins/jobs/.../builds/384/archive/venv/lib/python2.7/UserDict.py to /var/lib/jenkins/workspace/.../venv/lib/python2.7/UserDict.py
at hudson.plugins.copyartifact.CopyArtifact.copyOne(CopyArtifact.java:632)
at hudson.plugins.copyartifact.CopyArtifact.copy(CopyArtifact.java:575)
at hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:535)
at hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:473)
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.Build$BuildExecution.build(Build.java:206)
at hudson.model.Build$BuildExecution.doRun(Build.java:163)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504)
at hudson.model.Run.execute(Run.java:1794)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
This started happening on multiple pre-existing jobs that were working just fine prior to an upgrade of the copyartifact plugin from 1.38.1 to 1.40. Rolling that plugin version back to 1.39.1 fixed the issue.
Attachments
Issue Links
- is blocked by
-
-
- Open
-
Activity
Lance Johnston, let me know followings:
- Do you use master/agent mode?: https://wiki.jenkins.io/display/JENKINS/Distributed+builds
- Is /usr/lib/python2.7/UserDict.py exists when copying?
- I want to know whether it’s a issue of dead links.
- Is /usr/lib/python2.7/UserDict.py readable from the user “jenkins”?
ikedam
added a comment - Lance Johnston , let me know followings:
Do you use master/agent mode?: https://wiki.jenkins.io/display/JENKINS/Distributed+builds
Is /usr/lib/python2.7/UserDict.py exists when copying?
I want to know whether it’s a issue of dead links.
Is /usr/lib/python2.7/UserDict.py readable from the user “jenkins”?
- Do you use master/agent mode?: https://wiki.jenkins.io/display/JENKINS/Distributed+builds - Yes
- Is /usr/lib/python2.7/UserDict.py exists when copying? - Yes
- I want to know whether it’s a issue of dead links.
- Is /usr/lib/python2.7/UserDict.py readable from the user “jenkins”? - Yes
Lance Johnston
added a comment -
Do you use master/agent mode?: https://wiki.jenkins.io/display/JENKINS/Distributed+builds - Yes
Is /usr/lib/python2.7/UserDict.py exists when copying? - Yes
I want to know whether it’s a issue of dead links.
Is /usr/lib/python2.7/UserDict.py readable from the user “jenkins”? - Yes
It looks that Jenkins doesn’t allow symlinks pointing out of workspace.
This was filed and resolved as SECURITY-162: https://jenkins.io/security/advisory/2015-02-27/
It cannot be fixed as it’s the security model of Jenkins itself.
I highly recommend you not to archive files directly, but to create an archive file (like tar.gz) and archive that file and copy it instead.
ikedam
added a comment - Lance Johnston
It looks that Jenkins doesn’t allow symlinks pointing out of workspace.
This was filed and resolved as SECURITY-162: https://jenkins.io/security/advisory/2015-02-27/
It cannot be fixed as it’s the security model of Jenkins itself.
I highly recommend you not to archive files directly, but to create an archive file (like tar.gz) and archive that file and copy it instead. Created JENKINS-52262.
ikedam
added a comment - Created JENKINS-52262 . One point and one question...
The "files" being archived are not outside the workspace. Rather, they are symbolic links within the workspace, pointing to locations outside the workspace.
If this is a problem with Jenkins itself, why does rolling back the Copy Artifact plugin from 1.40 to 1.39.1 fix the issue?
Lance Johnston
added a comment - One point and one question...
The "files" being archived are not outside the workspace. Rather, they are symbolic links within the workspace, pointing to locations outside the workspace.
If this is a problem with Jenkins itself, why does rolling back the Copy Artifact plugin from 1.40 to 1.39.1 fix the issue? > The "files" being archived are not outside the workspace. Rather, they are symbolic links within the workspace, pointing to locations outside the workspace.
I don’t know the detailed background of SECURITY-162, but I suppose that they worry about situations using those symlinks rather than copying. Malicious users may access files out of workspaces by creating a bad symlink.
> If this is a problem with Jenkins itself, why does rolling back the Copy Artifact plugin from 1.40 to 1.39.1 fix the issue?
Copyartifact 1.40 now accesses artifacts via ArtifactManager.
It provides generic mechanisms managing artifacts, such as compressing artifacts tranparently (Compress Artifacts plugin).
And SECURITY-162 looks applied to that ArtifactManager. I don’t know it’s not applied to the legacy mechanism.
ikedam
added a comment - > The "files" being archived are not outside the workspace. Rather, they are symbolic links within the workspace, pointing to locations outside the workspace.
I don’t know the detailed background of SECURITY-162, but I suppose that they worry about situations using those symlinks rather than copying. Malicious users may access files out of workspaces by creating a bad symlink.
> If this is a problem with Jenkins itself, why does rolling back the Copy Artifact plugin from 1.40 to 1.39.1 fix the issue?
Copyartifact 1.40 now accesses artifacts via ArtifactManager.
It provides generic mechanisms managing artifacts, such as compressing artifacts tranparently (Compress Artifacts plugin).
And SECURITY-162 looks applied to that ArtifactManager. I don’t know it’s not applied to the legacy mechanism. I added a note in https://wiki.jenkins.io/display/JENKINS/Copy+Artifact+Plugin?20180707#CopyArtifactPlugin-RecommendedusageofCopyartifact .
I know my bad English, and I expect someone improves the note.
ikedam
added a comment - I added a note in https://wiki.jenkins.io/display/JENKINS/Copy+Artifact+Plugin?20180707#CopyArtifactPlugin-RecommendedusageofCopyartifact .
I know my bad English, and I expect someone improves the note. 
This sounds like an issue of `VirtualFile`, and I added `core` to components.