Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer
I can confirm that: * The issue is present in Debian 11 (podman3.0.1+dfsg1-3+b2), I ran into it with fedora:latest. * And the issue is fixed in Debian Testing (podman 3.4.1+ds1-2). However Debian Testing's podman is not practical to install on Debian 11 (requires a newer libc), so it would be nice if a solution could be found there. In the short term the following workaround can be used: podman run --rm --security-opt seccomp=unconfined -it fedora:latest Not sure about the security implications though. -- Francois Gouget http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.
Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer
Yes, after installing podman_3.0.1+dfsg1-4_amd64.deb and golang-github-containers-common_0.33.4+ds1-2_all.deb from that page, the Fedora 35 examples work as expected. – Will On Sat, 9 Oct 2021 at 23:14, Reinhard Tartler wrote: > Control: fixed -1 3.3.1+ds2-1 > Control: tags -1 bullseye > > Thank you for your bugreport. > > On Tue, Oct 5, 2021 at 10:51 AM Will Thompson wrote: > >> 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. >> > > I believe this should be fixed with the changes I'm prepareing in the > context of #994451 > > Would you mind trying the packages at > https://people.debian.org/~siretart/bug.994451/ and let me know if they > fix this issue as well? I'm fairly confident that it does. > > Thank you. > > > -- > regards, > Reinhard >
Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer
Control: fixed -1 3.3.1+ds2-1 Control: tags -1 bullseye Thank you for your bugreport. On Tue, Oct 5, 2021 at 10:51 AM Will Thompson wrote: > 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. > I believe this should be fixed with the changes I'm prepareing in the context of #994451 Would you mind trying the packages at https://people.debian.org/~siretart/bug.994451/ and let me know if they fix this issue as well? I'm fairly confident that it does. Thank you. -- regards, Reinhard
Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer
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=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=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 libc62.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-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7 ii slirp4netns 1.0.1-2 ii uidmap1:4.8.1-1 Versions of packages podman suggests: pn containers-storage pn docker-compose -- no debconf information
