[WIP] daemon/archive: attempt to resolve leaking mounts during cp#43583
Closed
neersighted wants to merge 1 commit intomoby:masterfrom
Closed
[WIP] daemon/archive: attempt to resolve leaking mounts during cp#43583neersighted wants to merge 1 commit intomoby:masterfrom
neersighted wants to merge 1 commit intomoby:masterfrom
Conversation
This is a naive first attempt at resolving the issue reported in moby#38995 and moby#43390. This approach does pass the integration tests locally, and it passes my minimal reproduction. It additionally passes the short stress-test of the daemon. However, the attached integration test, while correct, does not properly fail, without this patch. This is because it is not triggered by Docker-in-Docker -- to see this bug, we have to be in the 'true root' mount namespace. There are a couple other possibilities we can explore -- the first one I see is an [alternate test location]. Testing the daemon without the container abstraction would take this from a regression test for `docker cp` to a test of the soundness of mount propagation during the special case of mounting the daemon root into the container. The second alternative is a completely different, larger-scale change, to use a disposable mount namespace in the engine to do all container mounting in daemon/archive. This is more invasive and harder to prototype, but less likely to have issues in the future as we can completely sidestep this category of issues (interactions with the root mount namespace). Eyeballs and input on this approach, or the merits of the other two approaches (as well as anything I haven't forseen) is appreciated. I would like feedback from upstream (especially on how to test/validate this) before I go to far ahead with more revisions. A prior attempt at solving this can be found at moby#38993. [alternate test location]: https://github.com/moby/moby/blob/c55a4ac7795c7606b548b38e24673733481e2167/daemon/daemon_linux_test.go Signed-off-by: Bjorn Neergaard <[email protected]>
Member
Author
|
Per discussion offline in the maintainers meeting, this approach is intractable because of the testing issue. While future test harnesses may be able to do end-to-end testing including the kernel <-> daemon interface, we don't have that capability at present and this is a band-aid. The conclusion was that |
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.
- What I did
This is a naive first attempt at resolving the issue reported in #38995 and #43390. This approach does pass the integration tests locally, and it passes my minimal reproduction. It additionally passes the short stress-test of the daemon.
However, the attached integration test, while correct, does not properly fail, without this patch. This is because it is not triggered by Docker-in-Docker -- to see this bug, we have to be in the 'true root' mount namespace.
There are a couple other possibilities we can explore -- the first one I see is an alternate test location. Testing the daemon without the container abstraction would take this from a regression test for
docker cpto a test of the soundness of mount propagation during the special case of mounting the daemon root into the container.The second alternative is a completely different, larger-scale change, to use a disposable mount namespace in the engine to do all container mounting in daemon/archive. This is more invasive and harder to prototype, but less likely to have issues in the future as we can completely sidestep this category of issues (interactions with the root mount namespace).
Eyeballs and input on this approach, or the merits of the other two approaches (as well as anything I haven't forseen) is appreciated. I would like feedback from upstream (especially on how to test/validate this) before I go to far ahead with more revisions.
A prior attempt at solving this can be found at #38993.
Signed-off-by: Bjorn Neergaard [email protected]
- How I did it
The current approach is ugly, but results in a minimally invasive change.
- Description for the changelog
Resolve mounts leaking during
docker cpwhen the docker root is mounted into the container (#38995, #43390).- How to verify it
Minimal reproduction:
Stress-test this change:
Guidance is needed on a proper regression test as the current tests will not fail under Docker-in-Docker.