Skip to content
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

Closed
moschroe opened this issue Dec 2, 2022 · 11 comments · Fixed by #19444
Closed
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@moschroe
Copy link

moschroe commented Dec 2, 2022

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 from lo present inside the container) and using the PID at .State.Pid, the namespace can be named and entered with ip netns attach $name $PID and ip 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:

  1. 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"):

[
    "",
    "/run/user/1000/netns/netns-30095655-50fc-2680-9c7d-722e8588916f"
]

The equivalent docker run --rm -i --name test-container --network=none docker.io/library/alpine:3.17 followed by docker 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:

Client:       Podman Engine
Version:      4.3.1
API Version:  4.3.1
Go Version:   go1.19.3
Git Commit:   814b7b003cc630bf6ab188274706c383f9fb9915-dirty
Built:        Thu Nov 10 15:59:17 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.28.0
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: /usr/bin/conmon is owned by conmon 1:2.1.5-1
    path: /usr/bin/conmon
    version: 'conmon version 2.1.5, commit: c9f7f19eb82d5b8151fc3ba7fbbccf03fdcd0325'
  cpuUtilization:
    idlePercent: 99.54
    systemPercent: 0.14
    userPercent: 0.32
  cpus: 64
  distribution:
    distribution: manjaro
    version: unknown
  eventLogger: journald
  hostname: USERMACHINE
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65537
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65537
  kernel: 5.15.78-1-MANJARO
  linkmode: dynamic
  logDriver: journald
  memFree: 43088547840
  memTotal: 67362869248
  networkBackend: cni
  ociRuntime:
    name: crun
    package: /usr/bin/crun is owned by crun 1.7-1
    path: /usr/bin/crun
    version: |-
      crun version 1.7
      commit: 40d996ea8a827981895ce22886a9bac367f87264
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: /usr/bin/slirp4netns is owned by slirp4netns 1.2.0-1
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 0
  swapTotal: 0
  uptime: 6h 38m 12.00s (Approximately 0.25 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /home/USER/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 0
    stopped: 2
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/USER/.local/share/containers/storage
  graphRootAllocated: 971047903232
  graphRootUsed: 894200315904
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 48
  runRoot: /run/user/1000/containers
  volumePath: /home/USER/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 1668092357
  BuiltTime: Thu Nov 10 15:59:17 2022
  GitCommit: 814b7b003cc630bf6ab188274706c383f9fb9915-dirty
  GoVersion: go1.19.3
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

# pacman -Qi podman
Name            : podman
Version         : 4.3.1-1
Description     : Tool and library for running OCI-based containers in pods
Architecture    : x86_64
URL             : https://github.com/containers/podman
Licenses        : Apache
Groups          : None
Provides        : None
Depends On      : catatonit  conmon  containers-common  crun  iptables  libdevmapper.so=1.02-64  libgpgme.so=11-64  libseccomp.so=2-64  slirp4netns
Optional Deps   : apparmor: for AppArmor support [installed]
                  btrfs-progs: support btrfs backend devices [installed]
                  netavark: for a new container-network-stack implementation [installed]
                  podman-compose: for docker-compose compatibility [installed]
                  podman-docker: for Docker-compatible CLI
Required By     : podman-compose
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 66,95 MiB
Packager        : David Runge <dvzrv@archlinux.org>
Build Date      : Do 10 Nov 2022 15:59:17 CET
Install Date    : Mi 16 Nov 2022 11:09:35 CET
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

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

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Dec 2, 2022
@rhatdan
Copy link
Member

rhatdan commented Dec 2, 2022

@Luap99 PTAL

@mheon
Copy link
Member

mheon commented Dec 2, 2022

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 --net=none no setup is required so we delegate to the OCI runtime. As such, we don't know the path to the namespace, though I suppose we could shove /proc/$containerpid/ns/net in the output of inspect.

@Luap99
Copy link
Member

Luap99 commented Dec 5, 2022

I think adding /proc/$containerpid/ns/net makes sense. I would prefer that over actually bind mounting the netns since this is more expensive and we would need to manually clean it up.

@moschroe Would /proc/$containerpid/ns/net work for you?

@github-actions
Copy link

github-actions bot commented Jan 5, 2023

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Jan 5, 2023

@moschroe Friendly ping

@q2dg
Copy link

q2dg commented Jan 6, 2023

This issue is blocking this other feature: GNS3/gns3-server#1811

@rhatdan
Copy link
Member

rhatdan commented Jan 6, 2023

@Luap99 can you just do your suggestion and we can move on.

@moschroe
Copy link
Author

moschroe commented Jan 7, 2023

@moschroe Friendly ping

Sorry, lost track of this issue. I built a workaround for one tool using the manually determined path in /proc but propagating that in the API response should certainly fix it for everything else as well. I wholeheartedly approve!

@github-actions
Copy link

github-actions bot commented Feb 7, 2023

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Jul 29, 2023

@Luap99 any time to work on this one?

@Luap99 Luap99 self-assigned this Jul 31, 2023
Luap99 added a commit to Luap99/libpod that referenced this issue Jul 31, 2023
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>
@Luap99
Copy link
Member

Luap99 commented Jul 31, 2023

PR #19444

Luap99 added a commit to Luap99/libpod that referenced this issue Jul 31, 2023
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>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Oct 30, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants