Unable to start rootless containers as users with long UIDs

[varesa]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

When trying to start rootless containers as a user with a large UID, the attach socket path gets truncated and the container fails to start.

Steps to reproduce the issue:

1. Prepare users with varying lengths of UIDs:

desktop ~ # useradd -u 10000000 demo1
desktop ~ # useradd -u 100000000 demo2
desktop ~ # useradd -u 1000000000 demo3
desktop ~ # for i in 1 2 3; do usermod --add-subuids 2${i}00000-2${i}65536 demo$i && usermod --add-subgids 2${i}00000-2${i}65536 demo$i; done

2. Try to start rootless containers:

desktop ~ # su - demo1
[demo1@desktop ~]$ podman run --rm -ti busybox echo OK
[...]
OK

desktop ~ # su - demo2
[demo2@desktop ~]$ podman run --rm -ti busybox echo OK
[...]
Error: failed to connect to container's attach socket: /tmp/run-100000000/libpod/tmp/socket/d8924f379945226c221044db51b5544b8e017b7e46ec83cd198f15f2131464e4/attac: dial unixpacket /tmp/run-100000000/libpod/tmp/socket/d8924f379945226c221044db51b5544b8e017b7e46ec83cd198f15f2131464e4/attac: connect: no such file or directory

desktop ~ # su - demo3
[demo3@desktop ~]$ podman run --rm -ti busybox echo OK
[...]
Error: failed to connect to container's attach socket: /tmp/run-1000000000/libpod/tmp/socket/278216b0873f2c881eff86bfafc11ab29d2314f37a6eccdadf61a59ad833ed65/atta: dial unixpacket /tmp/run-1000000000/libpod/tmp/socket/278216b0873f2c881eff86bfafc11ab29d2314f37a6eccdadf61a59ad833ed65/atta: connect: no such file or directory

Describe the results you received:

If user UID exceeds 8 characters, container's attach socket path gets truncated

Describe the results you expected:

podman run should work with any allowed UID (e.g. 32-bit numbers on some distros)

Additional information you deem important (e.g. issue happens only occasionally):

Centralized authentication solutions like FreeIPA/Red Hat IdM default to a high range for domain accounts, like 909800000-... for my domain, so this prevents the usage of rootless podman in a FreeIPA domain deployed using default settings.

Output of podman version:

[demo3@desktop ~]$ podman version
Version:      2.2.1
API Version:  2.1.0
Go Version:   go1.14.10
Built:        Tue Dec  8 16:37:43 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

[demo3@desktop ~]$ podman info --debug
host:
  arch: amd64
  buildahVersion: 1.18.0
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.22-2.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.22, commit: c93fb161acdf210143641c432bd8c448788bb093'
  cpus: 16
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: journald
  hostname: desktop.mydomain.fi
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1004
      size: 1
    - container_id: 1
      host_id: 2300000
      size: 65537
    uidmap:
    - container_id: 0
      host_id: 1000000000
      size: 1
    - container_id: 1
      host_id: 2300000
      size: 65537
  kernel: 5.8.12-200.fc32.x86_64
  linkmode: dynamic
  memFree: 1006473216
  memTotal: 67407085568
  ociRuntime:
    name: crun
    package: crun-0.16-3.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.16
      commit: eb0145e5ad4d8207e84a327248af76663d4e50dd
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /tmp/podman-run-1000000000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.fc32.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 0
  swapTotal: 0
  uptime: 2666h 9m 34.08s (Approximately 111.08 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/demo3/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.3.0-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.3
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/demo3/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /tmp/podman-run-1000000000/containers
  volumePath: /home/demo3/.local/share/containers/storage/volumes
version:
  APIVersion: 2.1.0
  Built: 1607438263
  BuiltTime: Tue Dec  8 16:37:43 2020
  GitCommit: ""
  GoVersion: go1.14.10
  OsArch: linux/amd64
  Version: 2.2.1

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

[demo3@desktop ~]$ rpm -q podman
podman-2.2.1-1.fc32.x86_64

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.):

Physical Fedora 32 installation running 5.8.12-200.fc32.x86_64

[varesa]

Some additional testing:
Containers can be started with -d, and will run fine. However trying to podman attach <cid> will run into the same error

[Luap99]

Duplicate of #8798. Fixed in #8933.

[varesa]

After some time learning how to get along with delve, I found out:

• what caused the issue
• that it wasn't present in master anymore
• that it was fixed in fdbc278
• this issue is a duplicate of Socket truncated with long user names using default $XDG_RUNTIME_DIR #8798