rootfs: remove /proc/net/dev from allowed overmount list #4817
Conversation
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
This was added in 2ee9cbb ("It's /proc/stat, not /proc/stats") with no actual justification, and doesn't really make much sense on further inspection: * /proc/net is a symlink to "self/net", which means that /proc/net/dev is a per-process file, and so overmounting it would only affect pid1. Any other program that cares about /proc/net/dev would see their own process's configuration, and unprivileged processes wouldn't be able to see /proc/1/... data anyway. In addition, the fact that this is a symlink means that runc will deny the overmount because /proc/1/net/dev is not in the proc overmount allowlist. This means that this has not worked for many years, and probably never worked in the first place. * /proc/self/net is already namespaced with network namespaces, so the primary argument for allowing /proc overmounts (lxcfs-like masking of procfs files to emulate namespacing for files that are not properly namespaced for containers -- such as /proc/cpuinfo) is moot. It goes without saying that lxcfs has never overmounted /proc/self/net/... files, so the general "because lxcfs" justification doesn't hold water either. * The kernel has slowly been moving towards blocking overmounts in /proc/self/. Linux 6.12 blocked overmounts for fd, fdinfo, and map_files; future Linux versions will probably end up blocking everything under /proc/self/. Fixes: 2ee9cbb ("It's /proc/stat, not /proc/stats") Signed-off-by: Aleksa Sarai <[email protected]>
|
(This was added in #560.) |
AkihiroSuda
approved these changes
Jul 21, 2025
lifubang
approved these changes
Jul 21, 2025
|
@kolyshkin Yeah, probably. |
This was referenced Jul 25, 2025
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.
This was added in 2ee9cbb ("It's /proc/stat, not /proc/stats") with
no actual justification, and doesn't really make much sense on further
inspection:
/proc/net is a symlink to "self/net", which means that /proc/net/dev
is a per-process file, and so overmounting it would only affect pid1.
Any other program that cares about /proc/net/dev would see their own
process's configuration, and unprivileged processes wouldn't be able
to see /proc/1/... data anyway.
In addition, the fact that this is a symlink means that runc will
deny the overmount because /proc/1/net/dev is not in the proc
overmount allowlist. This means that this has not worked for many
years, and probably never worked in the first place.
/proc/self/net is already namespaced with network namespaces, so the
primary argument for allowing /proc overmounts (lxcfs-like masking of
procfs files to emulate namespacing for files that are not properly
namespaced for containers -- such as /proc/cpuinfo) is moot.
It goes without saying that lxcfs has never overmounted
/proc/self/net/... files, so the general "because lxcfs"
justification doesn't hold water either.
The kernel has slowly been moving towards blocking overmounts in
/proc/self/. Linux 6.12 blocked overmounts for fd, fdinfo, and
map_files; future Linux versions will probably end up blocking
everything under /proc/self/.
Fixes #4771
Signed-off-by: Aleksa Sarai [email protected]