fix: copy relative symlinks correctly between stages #2924
Merged
Conversation
This file contains 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
dtrudg
force-pushed
the
issue-2607
branch
8 times, most recently
from
d122abe
to
b391f65
Compare
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
wobito
approved these changes
May 23, 2024
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.
Description of the Pull Request (PR):
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.This fixes or addresses the following GitHub issues:
%filesfrom stage fails to copy relative symlinks #2607Before submitting a PR, make sure you have done the following:
make checkand tested this PR locally with amake test, andmake testallif possible (see CONTRIBUTING.md).