fix(transfer): resolve container paths against declared bind mounts - #260
Open
ndeloof wants to merge 1 commit into
Open
fix(transfer): resolve container paths against declared bind mounts#260ndeloof wants to merge 1 commit into
ndeloof wants to merge 1 commit into
Conversation
The container-FS transferrer anchored both directions at the bundle's rootfs. That directory backs only the paths no mount covers: where the runtime spec declares a bind mount, the container's mount namespace has the source mounted over the destination, so the rootfs entry underneath is shadowed. Importing to such a path therefore produced a file the container never sees, and exporting from one archived whatever the rootfs happened to hold instead of the mounted content. Neither reported an error. resolveMountRoot reads the bundle spec and maps a container-view path onto the directory backing it, preferring the longest matching bind destination so a nested mount wins over its parent. Both directions go through it, keeping the import and export views consistent with the container's own. A bundle with no readable or parseable config.json resolves to the rootfs, so callers that supply no mount information are unaffected. Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
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.
The container-FS transferrer anchors both directions at the bundle's rootfs. That directory backs only the paths no mount covers: where the runtime spec declares a bind mount, the container's mount namespace has the source mounted over the destination, so the rootfs entry underneath is shadowed.
Importing to such a path therefore produces a file the container never sees, and exporting from one archives whatever the rootfs happens to hold rather than the mounted content. Neither reports an error.
resolveMountRootreads the bundle spec and maps a container-view path onto the directory backing it, preferring the longest matching bind destination so a nested mount wins over its parent. Both directions go through it.A bundle with no readable or parseable
config.jsonresolves to the rootfs, so callers supplying no mount information are unaffected.Tests
TestReadPathImportLandsInBindSourceandTestWritePathExportReadsBindSourceassert the observable effect rather than the mapping: the import must land in the mount source and not in the shadowed rootfs entry, and the export must carry the mounted bytes where the rootfs holds different content at the same name. Both fail on the previous behaviour.TestResolveMountRootSelectsLongestDestinationcovers nesting, an uncovered path, and a sibling whose name merely shares the prefix.