podman system service for localhost not binding in dual stack on dual stack system

[Omar007]

Issue Description

Running podman system service tcp://localhost:2375 on a dual stack system binds only to IPv4. It can be forced to bind to IPv6 using ::1 but then it's not binding to IPv4. It's also not possible to supply both a 127.0.0.1 and ::1 url as argument as it only expects 1 argument.

Steps to reproduce the issue

1. Run podman system service tcp://localhost:2375
2. Observe logs outputting time="2024-02-14T18:25:45Z" level=info msg="API service listening on \"127.0.0.1:2375\". URI: \"tcp://localhost:2375\""
3. Try to curl -6 localhost:2375 and observe failure

Describe the results you received

It only bound to one of the IP stacks; IPv4, 127.0.0.1

Describe the results you expected

Binding to both IP stacks; IPv4, 127.0.0.1 and IPv6, ::1

podman info output

host:
  arch: amd64
  buildahVersion: 1.33.3
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.8-2.fc39.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.8, commit: '
  cpuUtilization:
    idlePercent: 91.75
    systemPercent: 2.93
    userPercent: 5.32
  cpus: 64
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: container
    version: "39"
  eventLogger: file
  freeLocks: 2048
  hostname: podman-test-f4dbc9d6c-fnvgh
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 1
      size: 999
    - container_id: 1000
      host_id: 1001
      size: 64535
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 1
      size: 999
    - container_id: 1000
      host_id: 1001
      size: 64535
  kernel: 6.6.2-arch1-1
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 34240225280
  memTotal: 270330986496
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.10.0-1.fc39.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.10.0
    package: netavark-1.10.1-5.fc39.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.10.1
  ociRuntime:
    name: crun
    package: crun-1.14-1.fc39.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.14
      commit: 667e6ebd4e2442d39512e63215e79d693d0780aa
      rundir: /tmp/podman-run-1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20231230.gf091893-1.fc39.x86_64
    version: |
      pasta 0^20231230.gf091893-1.fc39.x86_64
      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: /tmp/podman-run-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: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.2-1.fc39.x86_64
    version: |-
      slirp4netns version 1.2.2
      commit: 0ee2d87523e906518d34a6b423271e4826f71faf
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 1922h 26m 3.00s (Approximately 80.08 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/podman/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/podman/.local/share/containers/storage
  graphRootAllocated: 499174019072
  graphRootUsed: 193573765120
  graphStatus:
    Backing Filesystem: overlayfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /tmp/containers-user-1000/containers
  transientStore: false
  volumePath: /home/podman/.local/share/containers/storage/volumes
version:
  APIVersion: 4.9.0
  Built: 1706090847
  BuiltTime: Wed Jan 24 10:07:27 2024
  GitCommit: ""
  GoVersion: go1.21.6
  Os: linux
  OsArch: linux/amd64
  Version: 4.9.0

Podman in a container

Yes

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

[Luap99]

This is expected, the system service only support listening on one socket at a time so it cannot listen on ::1 and 127.0.0.1 at the same time. We also just use the golang API to bind the address and it seems like it does not support it: golang/go#9334. So if we want to support that than we would have to do this explicitly which is unlikely. If you truly need both you can start two podman system service processes with each url.

Also what is you goal by binding to localhost. It is insecure to expose the service via tcp even if it is just localhhost as all processes on the host can connect to it without access restrictions. Using a unix socket for local connections should be preferred.

[Omar007]

Ok fair enough, thank you for that information. I see the issue mentions not using a hostname but that would bind it to all and I don't want that haha. Guess running 2 service processes would make the most sense for now then 🤔

Also what is you goal by binding to localhost. ... Using a unix socket for local connections should be preferred.

Containerized workflows. I could shuffle volumes around to use unix sockets but that makes the setup more convoluted/complicated so localhost TCP seemed like the most sane way to do things in this context.