Uses/requires CNI for slirp4ns

[ensc]

/kind bug

Description

When running podman in root mode, it requires/uses CNI to build slirp4ns networks. In rootless mode with same parameters, CNI is not used.

CNI is problematic because it messes around with iptables directly which breaks when they are managed externally. For this, I need a pure userspace solution (more or less like dockerd --iptables=false) like slirp4ns.

Steps to reproduce the issue:

1. rm -rf /etc/cni/net.d (or keep it and use podman inspect later to see whether CNI is used)

2. run as root:

   podman run -it --network=slirp4ns fedora:31
   

3. run as user:

   podman run -it --network=slirp4ns fedora:31
   

Describe the results you received:

Step 2 fails with

ERRO[0000] CNI network "slirp4ns" not found             

Step 3 succeeds.

Describe the results you expected:

Step 2 succeeds and CNI is not used.

Output of podman version:

Version:            1.6.2
RemoteAPI Version:  1
Go Version:         go1.13.1
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.13.1
  podman version: 1.6.2
host:
  BuildahVersion: 1.11.3
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.2-1.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.2, commit: 186a550ba0866ce799d74006dab97969a2107979'
  Distribution:
    distribution: fedora
    version: "31"
  MemFree: 2040983552
  MemTotal: 32669814784
  OCIRuntime:
    name: crun
    package: crun-0.10.6-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.10.6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 4177784832
  SwapTotal: 4294963200
  arch: amd64
  cpus: 8
  eventlogger: journald
  hostname: ensc-virt.intern.sigma-chemnitz.de
  kernel: 5.3.15-300.fc31.x86_64
  os: linux
  rootless: false
  uptime: 26h 4m 9.38s (Approximately 1.08 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 26
  GraphDriverName: overlay
  GraphOptions:
    overlay.mountopt: nodev,metacopy=on
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  ImageStore:
    number: 35
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes

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

podman-1.6.2-2.fc31.x86_64

[mheon]

I think it's slirp4netns not slirp4ns - this seems to assume that you're naming a specific network to join the container to, not the slirp4netns network mode.

[ensc]

a sorry; played around too much with these parameters to find a solution. It happens for slirp4netns too:

# podman run -it --network=slirp4netns fedora:31
Error: error configuring network namespace for container 333904201fd754e3ad250b20375637d729d8c57671737aa4bbe5509fc209e3d1: Missing CNI default network

or (when CNI networks are defined), the TAP interfaceis attached to the CNI bridge:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.5efd27246f02       no              veth51c30c92
                                                        vethc52bca13

# podman run -it --network=slirp4netns fedora:31

and in another shell

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.5efd27246f02       no              veth1b744da0
                                                        veth51c30c92
                                                        vethc52bca13

[mheon]

Ack, that definitely sounds like a bug in how we're configuring slirp as root.

[ensc]

To demonstrate the real problem:

1. Create a minimal CNI setup which does not touch the iptables

   {
       "cniVersion": "0.4.0",
       "name": "podman",
       "plugins": [
           {
               "type": "bridge",
               "bridge": "br0",
               "isGateway": false,
               "ipMasq": false,
               "ipam": {
                   "type": "host-local",
                   "routes": [
                       {
                           "dst": "0.0.0.0/0"
                       }
                   ],
                   "ranges": [
                       [
                           {
                               "subnet": "10.1.0.0/24",
                               "gateway": "10.1.0.1"
                           }
                       ]
                   ]
               }
           }
       ]
   }
   

2. (clear nat table)

3. Run as root

   # podman run --rm --publish=10000:10000  -it  --network=slirp4netns busybox
   

4. Execute in the container

   nc -l -p 10000
   

5. Monitor network traffic on the host in the background

   # tcpdump -i enp0s31f6 -nnn -s0 port 10000
   

6. Connect from the outside to port 10000 and send some data

   $ telnet my-host 10000
   abc
   

   Close connection, reconnect and play around a little bit

Output in step 5 shows the expected

17:41:36.869048 IP 192.168.0.132.43516 > 192.168.3.24.10000: Flags [SEW], seq 1272706154
17:41:36.869104 IP 192.168.3.24.10000 > 192.168.0.132.43516: Flags [S.E], seq 1468818041, ack 1272706155
17:41:36.869316 IP 192.168.0.132.43516 > 192.168.3.24.10000: Flags [.], ack 1

17:41:41.596255 IP 192.168.0.132.43516 > 192.168.3.24.10000: Flags [P.], seq 1:6, ack 1
17:41:41.596307 IP 192.168.3.24.10000 > 192.168.0.132.43516: Flags [.], ack 6

But sometimes the internal private IP appears:

17:41:42.094191 IP 192.168.0.132.43516 > 192.168.3.24.10000: Flags [P.], seq 6:7, ack 1
17:41:42.094225 IP 192.168.3.24.10000 > 192.168.0.132.43516: Flags [.], ack 7
17:41:42.094336 IP 10.0.2.100.10000 > 192.168.0.132.43516: Flags [.], ack 2
17:41:46.256096 IP 10.0.2.100.10000 > 192.168.0.132.43516: Flags [.], ack 2

[github-actions]

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

[rhatdan]

@AkihiroSuda Could you comment on this?

[AkihiroSuda]

Why are you trying to run slirp4netns as root?

[mheon]

I don't think this is a problem with Slirp itself - it sounds like we're not properly respecting the requested slirp4netns setting and applying CNI as well. A lot of networking code is written with the implicit assumption that root=CNI, rootless=slirp - I bet that's where this slipped in.

[mheon]

@ensc Can you possibly test #4853 and verify that it resolves the problem?