Netavark driver plugin cannot access host devices in rootless mode

[pcguy85]

Issue Description

During container setup it seems like rootless podman unconditionally creates a separate network namespace before delegating to the network backend (netavark in my case). For standard setups this is fine, but when a custom netavark plugin is in charge of the network this can lead so somewhat confusing behavior. In my case the custom driver expects to execute in the root network namespace where all host devices are available. But all it finds is the pasta device podman created. My guess is that running podman as root would fix this problem but running as root is not always desired/possible.

I don't know if this is a bug or desired behavior. After reading the documentation I expected netavark to be responsible for all networking related tasks. Or is there some setting the plugin can communicate to podman to suppress the pasta network namespace creation?

Steps to reproduce the issue

Steps to reproduce the issue

1. Configure user's container.conf: Set network_backend = "netavark" and add path containing mydriver binary to netavark_plugin_dirs
2. $ podman network create -d mydriver --interface-name mydev mynet
3. $ podman run --rm -it --network mynet docker.io/debian:bookworm /bin/bash

Describe the results you received

The mydriver plugin fails because it cannot find the mydev device.

Describe the results you expected

Expected shell prompt

podman info output

host:
  arch: amd64
  buildahVersion: 1.36.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.10+ds1-1+b1_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.10, commit: unknown'
  cpuUtilization:
    idlePercent: 99.67
    systemPercent: 0.13
    userPercent: 0.2
  cpus: 1
  databaseBackend: sqlite
  distribution:
    codename: trixie
    distribution: debian
    version: unknown
  eventLogger: journald
  freeLocks: 2048
  hostname: test-debian
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.9.8-amd64
  linkmode: dynamic
  logDriver: journald
  memFree: 394076160
  memTotal: 1015230464
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: Unknown
    package: Unknown
    path: /usr/local/libexec/podman/netavark
    version: netavark 1.11.0
  ociRuntime:
    name: crun
    package: crun_1.15-1_amd64
    path: /usr/bin/crun
    version: |-
      crun version 1.15
      commit: e6eacaf4034e84185fd8780ac9262bbf57082278
      rundir: /run/user/0/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt_0.0~git20240624.1ee2eca-1_amd64
    version: |
      pasta 0.0~git20240624.1ee2eca-1
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: false
    path: /run/podman/podman.sock
  rootlessNetworkCmd: pasta
  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: false
    seccompEnabled: true
    seccompProfilePath: ""
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_1.2.1-1+b1_amd64
    version: |-
      slirp4netns version 1.2.1
      commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
      libslirp: 4.8.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.5
  swapFree: 0
  swapTotal: 0
  uptime: 1h 24m 22.00s (Approximately 0.04 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  - mydriver
  volume:
  - local
registries: {}
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 8348200960
  graphRootUsed: 1708949504
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.2.0-dev
  Built: 1721064502
  BuiltTime: Mon Jul 15 19:28:22 2024
  GitCommit: 88c68a4b58d406d37b9f798aaa8c0b38728ec7f5
  GoVersion: go1.22.4
  Os: linux
  OsArch: linux/amd64
  Version: 5.2.0-dev

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

Virtualbox VM running Debian Trixie

Additional information

No response

[Luap99]

This is expected with the given design, netavark must always be executed in the rootless netns, compare #22943 (comment)

What are you trying to do here with the host netns? You cannot modify it in any way as the process will always be part of the podman userns so even if your plugin would be setuid it will not work. The only thing you could do is read the network settings but you will never have CAP_SYS_ADMIN for the host netns.
Given that I really see little reason to execute it in the hostns.

One option to work around that is to have a privileged helper daemon running on the host listing on some unix socket and then have the plugin connect over the socket and let the deamon do the actual work.

[Luap99]

I move this to discussion as this works as designed currently.

[pcguy85]

I see. Looks like I missed some bits about podman's rootless architecture. I'm trying to integrate podman with a third party system that handles most networking aspects. Said system is mostly incompatible with all options netavark currently offers.

I will have a look at the solution you suggested. Thank you for the explanation and helping me out.