fix: copy relative symlinks correctly between stages (release-4.1) #3031
Conversation
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
|
Failure due to ubuntu keyserver timeout |
dtrudg
approved these changes
Jun 20, 2024
cherry pick sylabs#2924 In a build stage, a valid relative symlink can be created that points to a location in the rootfs that is above the location of the symlink. E.g.: /usr/mydir/mysubdir/true -> ../../../bin/true This symlink is valid in the rootfs. It resolves to `/bin/true`. If we attempt to copy `/usr/mydir` into a new build stage, then prior to this PR the symlink would cause the copy to fail. We have been using `CopyFromTar` to copy from src `<stage1>/usr/mydir`, to `<stage2>/usr/mydir`. The `CopyFromTar` routines enforce that the target of a hard link or symlink must be under dst, or a fatal error is raised to avoid a breakout attack. When copying between stages our boundary is not dst, but the top level of the destination stage's rootfs. We must allow links to be created that are above dst, but within the stage rootfs. To resolve the issue, bring over enough code from `docker/docker/pkg/archive` that we can implement a `CopyFromTarWithRoot`, that performs the same as `CopyFromTar`, except that we can specify a destination root directory. Any hard links and symlink targets under this destination root directory are valid. Fixes sylabs#2607
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.
cherry pick #2924
In a build stage, a valid relative symlink can be created that points to a location in the rootfs that is above the location of the symlink. E.g.:
/usr/mydir/mysubdir/true -> ../../../bin/true
This symlink is valid in the rootfs. It resolves to
/bin/true.If we attempt to copy
/usr/mydirinto a new build stage, then prior to this PR the symlink would cause the copy to fail.We have been using
CopyFromTarto copy from src<stage1>/usr/mydir, to<stage2>/usr/mydir. TheCopyFromTarroutines enforce that the target of a hard link or symlink must be under dst, or a fatal error is raised to avoid a breakout attack.When copying between stages our boundary is not dst, but the top level of the destination stage's rootfs. We must allow links to be created that are above dst, but within the stage rootfs.
To resolve the issue, bring over enough code from
docker/docker/pkg/archivethat we can implement aCopyFromTarWithRoot, that performs the same asCopyFromTar, except that we can specify a destination root directory. Any hard links and symlink targets under this destination root directory are valid.Fixes #2607