New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
starting container with --network=none will not set up network namespace in filesystem #16716
Comments
@Luap99 PTAL |
The difference is that Podman is not creating a network namespace, but the OCI runtime. With other network modes, we create and manage the namespace ourselves to ensure it can be set up as required. For |
I think adding @moschroe Would |
A friendly reminder that this issue had no activity for 30 days. |
@moschroe Friendly ping |
This issue is blocking this other feature: GNS3/gns3-server#1811 |
@Luap99 can you just do your suggestion and we can move on. |
Sorry, lost track of this issue. I built a workaround for one tool using the manually determined path in |
A friendly reminder that this issue had no activity for 30 days. |
@Luap99 any time to work on this one? |
We do not use any special netns path for the netns=none case, however callers that inspect that may still wish to join the netns path directly without extra work to figure out /proc/$pid/ns/net. Fixes containers#16716 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
PR #19444 |
We do not use any special netns path for the netns=none case, however callers that inspect that may still wish to join the netns path directly without extra work to figure out /proc/$pid/ns/net. Fixes containers#16716 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
BUG REPORT
/kind bug
Description
podman inspect $container
does not yield.NetworkConfig.SandboxKey
when a container was started with--network=none
. I believe this to be a bug because a network namespace is created (there are no interfaces apart fromlo
present inside the container) and using the PID at.State.Pid
, the namespace can be named and entered withip netns attach $name $PID
andip netns exec $name $command
.The combination of setting up containers without network interfaces and then accessing their network namespace is needed to inject externally configured network interfaces (like wireguard) into an otherwise isolated container. While this is possible by using the PID, it would require reworking of existing tooling already compatible with docker.
Steps to reproduce the issue:
podman run --rm -i --name test-container --network=none docker.io/library/alpine:3.17
Describe the results you received:
The command
podman inspect test-container | jq ".[0].NetworkSettings | [.SandboxID, .SandboxKey]"
yields empty strings instead of the expected .SandboxKey (and optional .SandboxID).Root/non-root does not make a difference, neither does changing the network backend to netavark.
Describe the results you expected:
The network namespace should have been established in the filesystem and made accessible through the
.NetworkConfig.SandboxKey
key. Here a working example for--network=default
(or anything other than "none"):The equivalent
docker run --rm -i --name test-container --network=none docker.io/library/alpine:3.17
followed bydocker inspect test-container | jq ".[0].NetworkSettings | [.SandboxID, .SandboxKey]"
will accurately report the SandboxKey.Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info
:Package info (e.g. output of
rpm -q podman
orapt list podman
orbrew info podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
N/A
The text was updated successfully, but these errors were encountered: