[1.1] Fixes inability to use /dev/null when inside a container #3620
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
evanphx
force-pushed
the
b-remove-udev-dep
branch
from
fea204e
to
4932cf4
Compare
|
What distro needs this fix? |
AkihiroSuda
reviewed
Oct 3, 2022
|
It's not a specific distro that needs the fix, it was more of a one-off. I was experimenting with running systemd inside a containerd managed container, with docker installed inside the that container (so, nested containerds). The installation of systemd didn't pull in udev (it was ubuntu) and thusly /dev/{block,char} were not created. |
evanphx
force-pushed
the
b-remove-udev-dep
branch
3 times, most recently
from
f3a00d3
to
a3e87da
Compare
|
Looks like this PR was opened against the 1.1 branch; the standard flow is to open against main, and then cherry-pick backports; could you change the PR to tarter "main"? |
|
@thaJeztah The code on main has been reorganized so the patch wouldn't be easily backported. I'm happy to open an additional PR with the fix for main. |
evanphx
added a commit
to lab47/runc
that referenced
this pull request
Oct 3, 2022
This is a forward port of opencontainers#3620 The original code depended on the origin filesystem to have /dev/{block,char} populated. This is done by udev normally and while is very common non-containerized systemd installs, it's very easy to start systemd in a container created by runc itself and not have /dev/{block,char} populated. When this occurs, the following error output is observed: $ docker run hello-world docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error reopening /dev/null inside container: open /dev/null: operation not permitted: unknown. /dev/null can't be opened because it was not added to the deviceAllowList, as there was no /dev/char directory. The change here utilizes the fact that when sysfs in in use, there is a /sys/dev/{block,char} that is kernel maintained that we can check. Signed-off-by: Evan Phoenix <evan@phx.io>
|
@thaJeztah Went ahead and did the forward port: #3623 |
AkihiroSuda
changed the title
|
Thanks! Just making sure that we have all fixes in |
|
I suggest we discuss this in #3623 first. |
evanphx
added a commit
to lab47/runc
that referenced
this pull request
Oct 8, 2022
This is a forward port of opencontainers#3620 The original code depended on the origin filesystem to have /dev/{block,char} populated. This is done by udev normally and while is very common non-containerized systemd installs, it's very easy to start systemd in a container created by runc itself and not have /dev/{block,char} populated. When this occurs, the following error output is observed: $ docker run hello-world docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error reopening /dev/null inside container: open /dev/null: operation not permitted: unknown. /dev/null can't be opened because it was not added to the deviceAllowList, as there was no /dev/char directory. The change here utilizes the fact that when sysfs in in use, there is a /sys/dev/{block,char} that is kernel maintained that we can check. Signed-off-by: Evan Phoenix <evan@phx.io>
evanphx
added a commit
to lab47/runc
that referenced
this pull request
Oct 8, 2022
This is a forward port of opencontainers#3620 The original code depended on the origin filesystem to have /dev/{block,char} populated. This is done by udev normally and while is very common non-containerized systemd installs, it's very easy to start systemd in a container created by runc itself and not have /dev/{block,char} populated. When this occurs, the following error output is observed: $ docker run hello-world docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error reopening /dev/null inside container: open /dev/null: operation not permitted: unknown. /dev/null can't be opened because it was not added to the deviceAllowList, as there was no /dev/char directory. The change here utilizes the fact that when sysfs in in use, there is a /sys/dev/{block,char} that is kernel maintained that we can check. Signed-off-by: Evan Phoenix <evan@phx.io>
|
#3623 is merged, please backport |
evanphx
force-pushed
the
b-remove-udev-dep
branch
from
a3e87da
to
7fa15e0
Compare
|
@kolyshkin ready to go! |
|
CI centos-stream-8 timed out; restarted. |
AkihiroSuda
requested changes
Oct 18, 2022
This is a forward port of opencontainers#3620 The original code depended on the origin filesystem to have /dev/{block,char} populated. This is done by udev normally and while is very common non-containerized systemd installs, it's very easy to start systemd in a container created by runc itself and not have /dev/{block,char} populated. When this occurs, the following error output is observed: $ docker run hello-world docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error reopening /dev/null inside container: open /dev/null: operation not permitted: unknown. /dev/null can't be opened because it was not added to the deviceAllowList, as there was no /dev/char directory. The change here utilizes the fact that when sysfs in in use, there is a /sys/dev/{block,char} that is kernel maintained that we can check. Signed-off-by: Evan Phoenix <evan@phx.io> (cherry picked from commit 462e719)
evanphx
force-pushed
the
b-remove-udev-dep
branch
from
7fa15e0
to
3b95828
Compare
|
@AkihiroSuda No problem, done! |
AkihiroSuda
approved these changes
Oct 20, 2022
Just a follow up on this. @evanphx's fix is actually useful for systems running on top of LXD. (possibly in certain configuration, although I hit this with very standard setup IMO) So this is probably more common than you'd expect. I am certainly very grateful for this fix. 🙏 |
Merged
1 task
This was referenced Apr 25, 2023
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 original code depended on the origin filesystem to have /dev/{block,char} populated. This is done by udev normally and while is very common non-containerized systemd installs, it's very easy to start systemd in a container created by runc itself and not have /dev/{block,char} populated. When this occurs, the following error output is observed:
$ docker run hello-world
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error reopening /dev/null inside container: open /dev/null: operation not permitted: unknown.
/dev/null can't be opened because it was not added to the deviceAllowList, as there was no /dev/char directory. The change here utilizes the fact that when sysfs in in use, there is a /sys/dev/{block,char} that is kernel maintained that we can check.
I'd also recommend having a base allow list that includes /dev/null (1:3) since runc implicitly depends on it.