runsc: When mounting a new procfs fails, fall back to recursive bind-mount.#11097
Merged
Conversation
copybara-service
Bot
force-pushed
the
test/cl691672104
branch
7 times, most recently
from
16ddc95 to
315c869
Compare
…mount. As part of sandbox startup, `runsc` needs to set up a chroot environment with a minimal working `procfs` filesystem mounted within. However, doing so from within a container (as applications like Dangerzone do) may fail, because in the container runtime's default configuration, some paths of the procfs filesystem visible from within the container may be obstructed. This prevents mounting new unobstructed instances of `procfs`. This change detects this case and falls back to the previous behavior of using a recursive bind-mount of `/proc` in such a case. The obstructed subdirectories of procfs are preserved in this case, which is fine because we only need a very minimal subset of `procfs` to actually work. Additionally, `runsc` actually only needs a few kernel parameter files and `/proc/self` in order to work. So this change sets up a `tmpfs` mount that contains just those files, with the kernel parameter files being plainly copied and `/proc/self` being a symlink to the one present in the mounted view of `procfs` (regardless of which mounting method was used). The `runtime_in_docker` test will continuously verify that this fallback mechanism works to avoid similar breakage in the future. Credits to @avagin for figuring out this solution. Fixes #10944. PiperOrigin-RevId: 692310347
copybara-service
Bot
force-pushed
the
test/cl691672104
branch
from
315c869 to
6adc072
Compare
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
1 participant
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.
runsc: When mounting a new procfs fails, fall back to recursive bind-mount.
As part of sandbox startup,
runscneeds to set up a chroot environmentwith a minimal working
procfsfilesystem mounted within. However, doingso from within a container (as applications like Dangerzone do) may fail,
because in the container runtime's default configuration, some paths of the
procfs filesystem visible from within the container may be obstructed. This
prevents mounting new unobstructed instances of
procfs.This change detects this case and falls back to the previous behavior of
using a recursive bind-mount of
/procin such a case. The obstructedsubdirectories of procfs are preserved in this case, which is fine because
we only need a very minimal subset of
procfsto actually work.Additionally,
runscactually only needs a few kernel parameter filesand
/proc/selfin order to work. So this change sets up atmpfsmountthat contains just those files, with the kernel parameter files being
plainly copied and
/proc/selfbeing a symlink to the one present in themounted view of
procfs(regardless of which mounting method was used).The
runtime_in_dockertest will continuously verify that this fallbackmechanism works to avoid similar breakage in the future.
Credits to @avagin for figuring out this solution.
Fixes #10944.