[pkg-go] Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer

[Will Thompson]

Package: podman
Version: 3.0.1+dfsg1-3+b2
Severity: important

podman embeds a default seccomp policy, which based on my research is
identical to that used by docker. The policy embedded in the bullseye
version of podman is buggy when used to run a container whose glibc is
2.33.9000 or newer, due to that version's use of the clone3 syscall. The
lengthy commit message at
https://github.com/moby/moby/commit/9f6b562dd12ef7b1f9e2f8e6f2ab6477790a6594
explains the issue in considerable detail.

As a result, processes in such containers cannot spawn new threads, and
are practically unusable:

    $ podman run --rm -it registry.fedoraproject.org/fedora:35 curl http://example.com
    curl: (6) getaddrinfo() thread failed to start
    $ podman run --rm -it registry.fedoraproject.org/fedora:35 dnf update
    Errors during downloading metadata for repository 'fedora':
      - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]
    Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]

(I am just using Fedora 35 as an example. Over the lifetime of Bullseye
we can expect other distributions to adopt newer glibc, too.)

While it is possible to work around this issue by supplying a newer
policy to podman with:

    $ podman run --security-opt seccomp=/path/to/default.json ...

and this issue is probably fixed in bookworm's podman, it may be worth
considering updating the built-in policy in bullseye's podman.

NB. I'm reporting this bug from Endless OS, which is (nowadays) built
directly against the Bullseye repos, with a handful of packages overlaid
from our own repos. But podman and related packages are all drawn
directly from Bullseye, and I have reproduced this issue in a vanilla
Bullseye VM too.

-- System Information:
Distributor ID:	Endless
Description:	Endless 5.0.0
Release:	5.0.0
Codename:	bullseye
Architecture: x86_64

Kernel: Linux 5.11.0-35-generic (SMP w/8 CPU threads)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: unable to detect

Versions of packages podman depends on:
ii  conmon                           2.0.25+ds1-1.1
ii  containernetworking-plugins      0.9.0-1+b6
ii  crun                             0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1
ii  init-system-helpers              1.60
ii  iptables                         1.8.7-1
ii  libc6                            2.31-13
ii  libdevmapper1.02.1               2:1.02.175-2.1
ii  libgpgme11                       1.14.0-1+b2
ii  libseccomp2                      2.5.1-1

Versions of packages podman recommends:
ii  buildah                                           1.19.6+dfsg1-1+b6
ii  catatonit                                         0.1.5-2
ii  fuse-overlayfs                                    1.4.0-1
ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b7
ii  slirp4netns                                       1.0.1-2
ii  uidmap                                            1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  <none>
pn  docker-compose      <none>

-- no debconf information