containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.8k stars 2.42k forks source link

starting container with --network=none will not set up network namespace in filesystem #16716

Closed moschroe closed 1 year ago

moschroe commented 1 year ago

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

rhatdan commented 1 year ago

@Luap99 PTAL

mheon commented 1 year ago

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 commented 1 year ago

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[bot] commented 1 year ago

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

rhatdan commented 1 year ago

@moschroe Friendly ping

q2dg commented 1 year ago

This issue is blocking this other feature: https://github.com/GNS3/gns3-server/issues/1811

rhatdan commented 1 year ago

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

moschroe commented 1 year ago

@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[bot] commented 1 year ago

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

rhatdan commented 1 year ago

@Luap99 any time to work on this one?

Luap99 commented 1 year ago

PR #19444