Your message dated Fri, 15 Apr 2022 17:17:08 -0400
with message-id
<caj0ccezdngyafio-msw9m_udmoeytloqjvgynzhzcvoanw5...@mail.gmail.com>
and subject line Re: Bug#995777: podman: Cannot (effectively) use containers
with glibc 2.33.9000 or newer
has caused the Debian Bug report #995777,
regarding podman: Cannot (effectively) use containers with glibc 2.33.9000 or
newer
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
995777: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995777
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Version: 3.0.1+dfsg1-3+deb11u1
Thank you Francois, Will and everyone else who contributed. Debian stable
has been updated to libpod 3.0.1+dfsg1-3+deb11u1 which comes with the
necessary seccomp changes.
Best regards,
-rt
On Tue, Nov 9, 2021 at 9:57 AM Francois Gouget <[email protected]> wrote:
>
> 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 <[email protected]> http://fgouget.free.fr/
> The last time religion ruled, it was called the dark ages.
>
>
--
regards,
Reinhard
--- End Message ---
_______________________________________________
Pkg-go-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
