Fix docker cp when container source path is /#39357
Merged
thaJeztah merged 4 commits intomoby:masterfrom Jun 14, 2019
Merged
Conversation
33c5db2 to
cac6afc
Compare
CID=$(docker create alpine) docker cp $CID:/ out Signed-off-by: Brian Goff <cpuguy83@gmail.com> Signed-off-by: Tibor Vass <tibor@docker.com>
Codecov Report
@@ Coverage Diff @@
## master #39357 +/- ##
=========================================
Coverage ? 36.97%
=========================================
Files ? 612
Lines ? 45645
Branches ? 0
=========================================
Hits ? 16877
Misses ? 26480
Partials ? 2288 |
Member
|
087d4c3 to
d718ac0
Compare
Contributor
Author
added 2 commits
June 13, 2019 06:31
Signed-off-by: Tibor Vass <tibor@docker.com>
Before 7a7357d, archive.TarResourceRebase was being used to copy files and folders from the container. That function splits the source path into a dirname + basename pair to support copying a file: if you wanted to tar `dir/file` it would tar from `dir` the file `file` (as part of the IncludedFiles option). However, that path splitting logic was kept for folders as well, which resulted in weird inputs to archive.TarWithOptions: if you wanted to tar `dir1/dir2` it would tar from `dir1` the directory `dir2` (as part of IncludedFiles option). Although it was weird, it worked fine until we started chrooting into the container rootfs when doing a `docker cp` with container source set to `/` (cf 3029e76). The fix is to only do the path splitting logic if the source is a file. Unfortunately, 7a7357d added support for LCOW by duplicating some of this subtle logic. Ideally we would need to do more refactoring of the archive codebase to properly encapsulate these behaviors behind well- documented APIs. This fix does not do that. Instead, it fixes the issue inline. Signed-off-by: Tibor Vass <tibor@docker.com>
tiborvass
commented
Jun 13, 2019
thaJeztah
reviewed
Jun 13, 2019
thaJeztah
requested changes
Jun 13, 2019
tonistiigi
approved these changes
Jun 14, 2019
tonistiigi
reviewed
Jun 14, 2019
| sourceDir := resolvedPath | ||
| sourceBase := "." | ||
|
|
||
| if stat.Mode&os.ModeDir == 0 { // not dir |
Member
There was a problem hiding this comment.
I think this should be
if symlink {
opts = rebase
}
and always archivePath(resolvedPath).
Would be more understandable what is actually happening and wouldn't need the hack for removing the slash in the walker. But functionally they seem equivalent.
Contributor
Author
There was a problem hiding this comment.
Agreed. Can be done in a follow up.
Contributor
Author
|
@thaJeztah @kolyshkin updated with small requested change. |
Previously, getWalkRoot("/", "foo") would return "//foo"
Now it returns "/foo"
Signed-off-by: Tibor Vass <tibor@docker.com>
Contributor
Author
|
Failure is TestAPISwarmLeaderElection which is unrelated |
Member
|
Looks like s390x passed, but is hanging on the cleanup; https://jenkins.dockerproject.org/job/Docker-PRs-s390x/14591/console |
kaosagnt
added a commit
to kaosagnt/boot2docker-xfs-ng
that referenced
this pull request
Jun 24, 2019
…directory traversal. moby/moby#39357
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Another attempt at fixing #39348
Fixes #39348
Previous attempt at #39351
Before 7a7357d, archive.TarResourceRebase was being used to copy files
and folders from the container. That function splits the source path
into a dirname + basename pair to support copying a file:
if you wanted to tar
dir/fileit would tar fromdirthe filefile(as part of the IncludedFiles option).
However, that path splitting logic was kept for folders as well, which
resulted in weird inputs to archive.TarWithOptions:
if you wanted to tar
dir1/dir2it would tar fromdir1the directorydir2(as part of IncludedFiles option).Although it was weird, it worked fine until we started chrooting into
the container rootfs when doing a
docker cpwith container source setto
/(cf 3029e76 (#39292)).The fix is to only do the path splitting logic if the source is a file.
Unfortunately, 7a7357d added support for LCOW by duplicating some of
this subtle logic. Ideally we would need to do more refactoring of the
archive codebase to properly encapsulate these behaviors behind well-
documented APIs.
This fix does not do that. Instead, it fixes the issue inline.
Signed-off-by: Tibor Vass tibor@docker.com
I added a couple of more tests than the actual issue needs, just to make sure there are no other regressions compared to before the cve fix (3029e76).
Huge thanks to @cpuguy83 ❤️who worked tirelessly with me to understand the code and make this PR.