Pasta networking is not supported for rootless containers created by root with --userns=auto

[lukasmrtvy]

Issue Description

Pasta networking is not supported for rootless containers created by root with --userns=auto

Steps to reproduce the issue

Steps to reproduce the issue

1. sudo su
2. (root) podman run --rm -it --userns=auto --network pasta alpine

Describe the results you received

Error: invalid config provided: pasta networking is only supported for rootless mode

Describe the results you expected

Rootless container is created with pasta networking

podman info output

host:
  arch: amd64
  buildahVersion: 1.29.0
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.6-3.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.6, commit: '
  cpuUtilization:
    idlePercent: 63.62
    systemPercent: 9.68
    userPercent: 26.69
  cpus: 16
  distribution:
    distribution: fedora
    variant: coreos
    version: "37"
  eventLogger: journald
  hostname: ip-10-1-44-86
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.1.15-200.fc37.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 30585528320
  memTotal: 133530497024
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.8.1-1.fc37.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.1
      commit: f8a096be060b22ccd3d5f3ebe44108517fbf6c30
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +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
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-8.fc37.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 0h 57m 40.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphRootAllocated: 549150765056
  graphRootUsed: 5631844352
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 4.4.2
  Built: 1677669779
  BuiltTime: Wed Mar  1 11:22:59 2023
  GitCommit: ""
  GoVersion: go1.19.6
  Os: linux
  OsArch: linux/amd64
  Version: 4.4.2

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[sbrivio-rh]

Hi @lukasmrtvy, thanks for reporting this!

Error: invalid config provided: pasta networking is only supported for rootless mode

In some sense this is intended: pasta won't run as root because that would unnecessarily broaden privileges that can be used after exploiting an attack vector, and I didn't expect it to be particularly useful if Podman is anyway started as root.

It was a bit tricky (albeit doable) to safely handle the switch to a fallback unprivileged user when started by Podman, so we skipped that in the initial integration.

However, I guess it might be useful regardless of security considerations if you want a particular network configuration or if you just have some other reasons to run Podman as root for the moment.

It would be interesting if you could share your use case. Regardless of that, yes, I would still consider it as a missing feature.

Cc: @Luap99

[Luap99]

What is the use case here? As root it seems much more preferable to just use the kernel networking tools (bridge + veth pair or macvlan) as those should be much more performant.

[sbrivio-rh]

As root it seems much more preferable to just use the kernel networking tools (bridge + veth pair or macvlan)

Well, one might still want network isolation (against spoofing, packet forging, etc.), and throughput is usually higher for local port forwarding compared to building frames for veth or macvlan. But I'm also really curious to hear the use case here. :)

[lukasmrtvy]

I need to control nftables for rootless containers and that's not possible. It works ok in rootful with --userns=auto arg and oci hook containing iptables, although it's not that secure as a standalone rootless container.

@sbrivio-rh mentioned https://superuser.com/questions/1277697/making-routing-decisions-based-on-uid-using-nftables, but not sure if this would work.

Rootless container with slirp4netns / pasta with --userns=auto and custom iptables would be my use case ( DENYing outbound traffic to RFC1918 ranges ).

[sbrivio-rh]

@Luap99, you can assign this one to me, unless you plan to work on it as part of anything else you have pending.

[github-actions]

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

[rhatdan]

@sbrivio-rh Any progress?

[sbrivio-rh]

@sbrivio-rh Any progress?

No, sorry, not yet. It's a quite a low priority item on my list (but we're talking about weeks, not months).

[github-actions]

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

[Luap99]

cc @dgibson

[dgibson]

I need to control nftables for rootless containers and that's not possible. It works ok in rootful with --userns=auto arg and oci hook containing iptables, although it's not that secure as a standalone rootless container.

@lukasmrtvy I'm trying to understand this requirement a bit better. I'm assuming what you're doing here is modifying nftables rules in the host which will affect packets flowing to or from your container. Is that correct?

What exactly do those rules look like? Just being able to invoke pasta when root may not be enough here. Because pasta is forwarding traffic at L4, rather than L2, the rules you'd need to match them in the host may well be different from those you'd need for bridge based networking, and I doubt that's something we could practically address in podman or pasta.