Docker ubuntu:impish: Problem executing scripts DPkg::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true'

[Paride Legovini]

Sometime betweek August 28 and September 4 2021 the ubuntu:impish images published on dockerhub began erroring when executing the commands defined in /etc/apt/apt.conf.d/docker-clean.

I have this reproducer, which is probably not as minimal as it can be but looks reliable:

1. docker run -it --rm ubuntu:impish bash
2. apt update
3. apt install git
4. apt -y remove git

This results in:

E: Problem executing scripts DPkg::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true'
E: Sub-process returned an error code

*Removing* a package is not strictly needed to trigger the failure, but it seems that *two* apt operations are needed to trigger it, so this reproducer found by athos-ribeiro also works:

docker run -it --rm ubuntu:impish /bin/bash -c 'apt-get update; apt-get full-upgrade -y; apt-get install -y jq'

This doesn't happen when using ubuntu:hirsute.

[Thomas Bechtold (toabctl)]

Confirmed with:

docker run -it --rm ubuntu:impish /bin/bash -c 'apt-get update; apt-get full-upgrade -y; apt-get install -y jq'

[Athos Ribeiro (athos-ribeiro)]

Just for completeness here, we can trigger this by pullin the image by its digest:

docker run -it --rm ubuntu@sha256:5780eeea246d5e8e76c20dfedf03d4d9568cd4ba00af5a7e3762b6976df2b631 /bin/bash -c 'apt-get update; apt-get full-upgrade -y; apt-get install -y jq'

[Thomas Bechtold (toabctl)]

I entered the container and did a bit of debugging:

1) enable debugging output via "Debug::RunScripts "true";"
2) adjusted the docker-clean file:
# cat /etc/apt/apt.conf.d/docker-clean
APT::Update::Post-Invoke { "/usr/bin/true"; };
Dir::Cache::pkgcache ""; Dir::Cache::srcpkgcache "";

Running now the commands leads to:
# apt-get update; apt-get full-upgrade -y; apt-get install -y jq
Hit:1 http://archive.ubuntu.com/ubuntu impish InRelease
Hit:2 http://archive.ubuntu.com/ubuntu impish-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu impish-backports InRelease
Hit:4 http://security.ubuntu.com/ubuntu impish-security InRelease
Running external script: '/usr/bin/true'
Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke '/usr/bin/true'
E: Sub-process returned an error code
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
jq is already the newest version (1.6-2.1ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@9765dc3980e8:/# echo $?
0

[Paride Legovini (paride)]

The failure seems to come with libc6 2.34-0ubuntu2. In a fresh, non-upgraded ubuntu:impish container we currently have libc6 2.33-0ubuntu9, and I can install/remove jq without any failure. Upgrading libc6 (and libc-bin) to version 2.34-0ubuntu2 immediately causes the Post-Invoke commands to fail.

Reminds me of: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485

[Paride Legovini (paride)]

Another hint that we should look in the seccomp direction is that in a container launched with

  --security-opt seccomp=unconfined

the failure doesn't happen.

[Julian Andres Klode (juliank)]

I thought runc was fixed to produce ENOSYS by now for unknown syscalls to avoid that mess. We can't have every glibc update breaking containers like this...

405 clone3({flags=CLONE_VM|CLONE_VFORK, exit_signal=SIGCHLD, stack=0x7fc77e3d3000, stack_size=0x9000}, 88) = -1 EPERM (Operation not permitted)

Not sure if it applies to crun, someone check with that :D

[Julian Andres Klode (juliank)]

Should we just disable clone3() in glibc for now? http://patches-tcwg.linaro.org/patch/58206/

[Julian Andres Klode (juliank)]

Apparently there are fixed docker.io packages in

https://launchpad.net/~pascallj/+archive/ubuntu/docker.io-clone3

Still leaves podman and other runc consumers in the cold, though?

[Paride Legovini (paride)]

I can confirm this also affects crun, as expected. Tested with:

   podman run -it --runtime crun ubuntu:impish bash

[Florian Weimer (fweimer)]

Just to be clear, this is a container host bug which needs to be fixed. glibc works fine on real Linux kernels with and without clone3 support.

There is *supposed* to be a generic fix for this in docker and runc, but that broke temporarily upstream when support for other system calls (with higher system call numbers than clone3) was added. As far as I know, podman does not have the generic fix, so it currently needs to be updated for each new system call individually. (None of this depends on the system calls actually implemented in the host kernel, just to be clear.)

From a philosophical perspective, I also object to the notion that the container hosts developers get to define the Linux system call interface. That should be up to Linux maintainers in collaboration with userspace developers.

[Julian Andres Klode (juliank)]

@fweimer Suggestion was to avoid use of clone3 to keep things working until container runtimes are fixed.

[Kees Cook (kees)]

I hit this too. Host is hirsute.

It went so far as blowing up docker itself, with:

    runtime/cgo: pthread_create failed: Operation not permitted

[Kees Cook (kees)]

Host dockers need this:
https://github.com/moby/moby/pull/42681

[Lucas Kanashiro (lucaskanashiro)]

After reading the comments from this bug and the upstream discussions, I tried to find an approach which would minimize the size of the patch we would need to carry. I tested the following scenarios:

1) There is a docker upstream PR where tianon is trying to backport the fix to the 20.10 branch (the one we currently have in the archive), during the discussion, one of the upstream maintainers mentioned we might need just a newer version of runc to fix the issue:

https://github.com/moby/moby/pull/42836#issuecomment-916422920

After inspecting the runc git repo I found the following commit which seems to address the issue:

https://github.com/opencontainers/runc/commit/960182fdf03d99eb848c111ae791

I did backport this patch to the current runc package we have in Impish and tried to run the test case @athos-ribeiro provided in comment #2, using the docker.io package from the archive. But it did not work, the failure was still reproducible.

2) Since in the comment of the docker upstream maintainer he said we could need runc version 1.0.2 (in Impish we have 1.0.1), I imported this new version to our runc package and ran the same test case using docker.io from the archive. The issue was still there.

3) I kept the runc/1.0.2 installed in my VM and added tianon's patch backporting the fix to the docker.io package:

https://github.com/moby/moby/pull/42836/files

With the patched docker.io and runc/1.0.2 I was still able to reproduce the issue.

4) I removed all the custom packages from my VM and built the source package present in the PPA @juliank linked in comment #9 targeting Impish, and finally got the issue fixed (as others already mentioned). However, I am not happy in adding a patch with 1800+ lines containing a bunch of refactoring, the fix itself is less than 80 lines. I'd prefer to wait until the PR backporting the fix is merged:

https://github.com/moby/moby/pull/42836

For libpod, Sergio helped me to investigate this issue and he noticed that in Fedora (with glibc 2.34) it is working fine. There we can find a newer version of it compared to what we have in Ubuntu. I did some investigation in its upstream git repo and I did not find any specific patch addressing this issue to backport. The other option would be to update libpod to the Fedora's version but then it'd likely require the update of some dependencies. I do not believe we have time to do that and we are also in the Feature Freeze. Moreover, Reinhard, who is the libpod maintainer, would not be happy if we release Impish with a broken package.

With all that said, I believe the easier and the least worse solution would be to disable clone3 syscall from glibc. WDYT?

[Sergio Durigan Junior (sergiodj)]

Just a quick comment saying that I agree with Lucas' analysis here. It also seems to me that the glibc approach might be the least impactful way forward here.

[Julian Andres Klode (juliank)]

Disabling the clone3 call should only be a temporary workaround to get 21.10 released, this still must be fixed properly so it can be reenabled in 22.04.

I feel like that docker change is working around a bug in crun/runc regarding the default seccomp policy and not the proper fix either. It will do nothing to prevent this from happening again with the next syscall glibc uses.

Any changes for the host docker/runc/crun/libpod/whatever needs to be SRUed to all releases like we did for newfstatat() in glibc 2.33.

I really want to make sure that we don't just fix this issue but also don't end up with the same thing when glibc 2.35 or later drops with another syscall.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sergio Durigan Junior (sergiodj)]

On Saturday, September 11 2021, Julian Andres Klode wrote:

> Disabling the clone3 call should only be a temporary workaround to get
> 21.10 released, this still must be fixed properly so it can be reenabled
> in 22.04.

Absolutely; I totally agree.

> I really want to make sure that we don't just fix this issue but also
> don't end up with the same thing when glibc 2.35 or later drops with
> another syscall.

+1.

--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

[Michael Hudson-Doyle (mwhudson)]

So to hit this problem you need docker to include a syscall which:

 a) has a number higher than clone3 in its seccomp profile
 b) is known by libseccomp (as runc uses libseccomp to translate syscall names into numbers)

I think the syscall that we are hitting here is faccessat2, which was added to the default seccomp profile in 20.10 (in https://github.com/moby/moby/pull/41353) and is understood by libseccomp 2.5.0+, both of which have been backported to all stable releases. There are other syscalls in the default docker profile that could cause problems but they are not understood by any released version of libseccomp afaict.

I think the current version of https://github.com/moby/moby/pull/42836 should fix this (unfortunately I think Tianon found this version just a couple of hours after you were testing things). We don't need to backport runc or containerd to fix docker, but I don't know about, say, k8s. containerd probably needs a patch to _its_ default policy but I don't know who uses that.

I think the reason that podman works in fedora is because fedora has a newer version of the github.com/containers/common, newer even than the one vendored into podman's git tree (yay?) -- it looks like v0.40.0 added support for the clone3 syscall. That seems to be in sid, so we could sync that over to fix podman on impish (after a rebuild of course), not sure what we should do for hirsute users.

So, what to do now and what to do in the future.

For now, at the moment I feel reasonably confident that we can patch docker in supported releases before impish release, and hopefully there can be an upstream 20.10.9 release with the fix also before impish release. Then we can just tell docker users to update when they hit this and not feel tooooo guilty.

But what about other container runtimes? Don't know. As above, at least some versions of podman have problems.

My feeling currently is to not patch out the use of clone3 in libc. But I am prepared to be persuaded otherwise.

For the future, I'm not sure there's much that can be done other than to really pay attention to seccomp policy changes. Maybe it's possible to write a tool to print out the syscalls that are getting implicitly getting EPERM (probably using the amazingly useful https://github.com/hrw/syscalls-table/tree/master/tables) for a given runc seccomp policy and have a github action print out any changes to this set...

The dependence on libseccomp versions adds a wrinkle. Unless I'm misunderstanding things quite badly, the runc default policy contains a bunch of syscalls that are not understood by the current release of libseccomp but are in its git, so the next libseccomp release will "activate" these syscalls and possibly flip some others from ENOSYS to EPERM.

[Lucas Kanashiro (lucaskanashiro)]

I just tested the updated patch Tianon is proposing to docker upstream and it indeed fixed the issue, I believe it will be merged soon. I'll be preparing an upload adding this patch until upstream releases a new version.

[Michael Hudson-Doyle (mwhudson)]

We should probably snag https://github.com/containerd/containerd/pull/5982 as well.

[Lucas Kanashiro (lucaskanashiro)]

FWIW I have PRs up for review for docker and containerd here:

https://github.com/tianon/debian-docker/pull/13
https://github.com/tianon/debian-containerd/pull/30

Once they are approved I'll be uploading them.

[Reinhard Tartler (siretart)]

Hi, I've been doing the uploads for podman to debian and ubuntu for a while now.

I'm struggling with reproducing this bug with podman on impish. On a freshly "multipass launch'ed" impsish vm, I tried:

ubuntu@primary:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Impish Indri (development branch)
Release: 21.10
Codename: impish
ubuntu@primary:~$ sudo apt update -qq && sudo apt install crun runc podman
80 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
runc is already the newest version (1.0.1-0ubuntu2).
runc set to manually installed.
crun is already the newest version (0.17+dfsg-1).
podman is already the newest version (3.2.1+ds1-2ubuntu2).
0 upgraded, 0 newly installed, 0 to remove and 80 not upgraded.

ubuntu@primary:~$ podman run -it --runtime crun ubuntu:impish apt update -qq
27 packages can be upgraded. Run 'apt list --upgradable' to see them.

ubuntu@primary:~$ podman run -it --runtime runc ubuntu:impish apt update -qq
27 packages can be upgraded. Run 'apt list --upgradable' to see them.

ubuntu@primary:~$ sudo podman run -it --runtime runc ubuntu:impish apt update -qq
27 packages can be upgraded. Run 'apt list --upgradable' to see them.

ubuntu@primary:~$ sudo podman run -it --runtime crun ubuntu:impish apt update -qq
27 packages can be upgraded. Run 'apt list --upgradable' to see them.

@paride, can you please assist me with reproducing the issue?

[Athos Ribeiro (athos-ribeiro)]

@Reinhard, I can reproduce it locally, in impish, with

$ podman run -it --rm ubuntu:impish /bin/bash -c 'apt-get update; apt-get full-upgrade -y; apt-get install -y jq'

Which exists with:

E: Problem executing scripts DPkg::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true'
E: Sub-process returned an error code

Moreover, I also tried applying

https://github.com/containers/common/commit/78ac839f6d4dd0cf6dd44a67201e16ee3e890c1d
and the commits in
https://github.com/containers/common/pull/573/commits
and rebuilding podman, with no changes in the reproducer showed above.

The patched packages and deps are available at https://launchpad.net/~athos-ribeiro/+archive/ubuntu/podman-glibc-fix/+packages

[Reinhard Tartler (siretart)]

Thanks for the detailed steps. I am now able to reproduce and think I understand the issue.

It seems that you missed out the seccomp.json changes from https://github.com/containers/common/pull/573. Also, it seems that the code changes in that commit aren't strictly necessary to fix the reproducer. As a hotpatch, I was able to "fix" the issue with:

sudo curl -L https://raw.githubusercontent.com/containers/common/v0.41.0/pkg/seccomp/seccomp.json -o /usr/share/containers/seccomp.json

and then this command starts working:

podman run -it --rm ubuntu:impish /bin/bash -c 'apt-get -qq update; apt-get install -y libc6; apt-get install -y jq'

I'll see to provide a backport of that pull request for impish.

[Reinhard Tartler (siretart)]

It's actually more complicated. Seems that https://github.com/containers/common/pull/573 is necessary, but not sufficient to fix this issue. I'm backporting additional commits that made it into the containers/common 0.40.1 release (all of which update seccomp.json), which I believe are all relevant for fixing this issue. At least my local rebuild confirms that it fixes the reproducer.

I'll upload the fixed packages shortly.

[Reinhard Tartler (siretart)]

golang-github-opencontainers-specs uploaded to impish-proposed

[Reinhard Tartler (siretart)]

golang-github-containers-common uploaded to impish-proposed

[Reinhard Tartler (siretart)]

libpod uploaded to impish-proposed

[Launchpad Janitor (janitor)]

This bug was fixed in the package golang-github-opencontainers-specs - 1.0.2.41.g7413a7f-1ubuntu1

---------------
golang-github-opencontainers-specs (1.0.2.41.g7413a7f-1ubuntu1) impish; urgency=medium

  * seccomp: allow to override default errno return code, LP: #1943049

 -- Reinhard Tartler <email address hidden> Wed, 22 Sep 2021 13:50:20 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package libpod - 3.2.1+ds1-2ubuntu3

---------------
libpod (3.2.1+ds1-2ubuntu3) impish; urgency=medium

  * Rebuild against newer containers-common to fix seccomp issue, LP: #1943049

 -- Reinhard Tartler <email address hidden> Wed, 22 Sep 2021 14:40:40 -0400

[Paride Legovini (paride)]

While doing bug triage I stumbled on:

https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1944436

which is about the new close_range syscall. I'm not sure that could potentially end up breaking containers again as it happened with clone3, but a heads-up won't hurt.

[Steve Dodd (anarchetic)]

The long-term solution to all of this tediousness is probably for seccomp to be able to give some indication if a syscall is "new":

https://github.com/seccomp/libseccomp/issues/286

[Thomas Weise (tweise)]

Hi.

I am sorry to ask this, but:
Has the solution already become available for "normal" users?
(If not, I can just wait a bit, no problem.)
What would I need to do to get it working on my system?

The reason why I am asking is that I have already updated my system just now (apt-get update) and re-downloaded the ubuntu:21.10 image and my duplicated bug as reported in https://bugs.launchpad.net/cloud-images/+bug/1943293 still persists.

I am running Ubuntu 21.04 on my host system and use the ubuntu:21.10 container.

> sudo docker run --rm -it --entrypoint=/bin/bash "ubuntu:21.10"
# apt-get update && apt-get install -y curl
# curl https://www.bing.com
curl: (6) getaddrinfo() thread failed to start

Many thanks,
   Thomas.

P.S.: Argh, just now I see that under "affects", for "docker.io (Ubuntu)", it just says "confirmed", not "fix released" ... that explains it ^_^

[Lucas Kanashiro (lucaskanashiro)]

The fixes are ongoing. In impish, docker.io and containerd are stuck in -proposed because of a snapd bug which impacts their DEP-8 tests, the snapd team is working to fix it. In the other releases, I am working to backport the fixes to all of them, you can track the status in this bug:

https://bugs.launchpad.net/ubuntu/+source/runc/+bug/1938908

[Launchpad Janitor (janitor)]

This bug was fixed in the package docker.io - 20.10.7-0ubuntu4

---------------
docker.io (20.10.7-0ubuntu4) impish; urgency=medium

  * d/p/seccomp-add-support-for-clone3-syscall-in-default-policy.patch: Fix
    failure with new glibc clone3 syscall adding it to the default seccomp
    policy (LP: #1943049).

 -- Lucas Kanashiro <email address hidden> Fri, 10 Sep 2021 15:34:38 -0300

[Michael Hudson-Doyle (mwhudson)]

It's also worth saying that there is a glibc in proposed which disables the use of the problematic syscall because it causes problems with electron apps, which reduces the urgency a little. But we should still get the fixes everywhere because clone3 will for sure be enabled again during the jj cycle.

[Thomas Weise (tweise)]

Hi.

I am not entirely sure if that is related to what is currently going on, but I just tried to replicate my original report https://bugs.launchpad.net/cloud-images/+bug/1943293, which you can also find above as https://bugs.launchpad.net/cloud-images/+bug/1943049/comments/39.
I am now getting a *different* error from before:

sudo docker run --rm -it --entrypoint=/bin/bash "ubuntu:21.10"
root@15c0613638fc:/# apt-get update && apt-get install -y curl
Get:1 http://archive.ubuntu.com/ubuntu impish InRelease [269 kB]
Get:2 http://security.ubuntu.com/ubuntu impish-security InRelease [90.7 kB]
Get:3 http://archive.ubuntu.com/ubuntu impish-updates InRelease [90.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu impish-backports InRelease [90.7 kB]
Get:5 http://archive.ubuntu.com/ubuntu impish/main amd64 Packages [1809 kB]
Get:6 http://archive.ubuntu.com/ubuntu impish/multiverse amd64 Packages [255 kB]
Get:7 http://archive.ubuntu.com/ubuntu impish/universe amd64 Packages [16.7 MB]
Get:8 http://archive.ubuntu.com/ubuntu impish/restricted amd64 Packages [119 kB]
Fetched 19.5 MB in 12s (1682 kB/s)
Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true'
E: Sub-process returned an error code

and then:

root@4479609faaa5:/# curl
bash: curl: command not found

Here is some system information:

*Inside* the container:

root@15c0613638fc:/# uname -a
Linux 15c0613638fc 5.11.0-37-generic #41-Ubuntu SMP Mon Sep 20 16:39:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
x86_64 GNU/Linux

root@15c0613638fc:/# lsb_release -a
bash: lsb_release: command not found

On my *host* system:

$ uname -a
Linux home 5.11.0-37-generic #41-Ubuntu SMP Mon Sep 20 16:39:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 21.04
Release: 21.04
Codename: hirsute

The system is fully updated, i.e. sudo apt-get update && sudo apt-get upgrade does not lead to any change.

In the past, the installation of curl would work, but then "curl https://bing.com" would fail.
Now the installation of curl fails.

[Launchpad Janitor (janitor)]

This bug was fixed in the package golang-github-containers-common - 0.38.16+ds1-1ubuntu1

---------------
golang-github-containers-common (0.38.16+ds1-1ubuntu1) impish; urgency=medium

  * Update seccomp profile for glibc_2.34 changes, LP: #1943049

 -- Reinhard Tartler <email address hidden> Wed, 22 Sep 2021 10:40:25 -0400

[Brian Murray (brian-murray)]

Hello Paride, or anyone else affected,

Accepted containerd into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/containerd/1.5.5-0ubuntu2~21.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Paride, or anyone else affected,

Accepted containerd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/containerd/1.5.5-0ubuntu2~20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Paride, or anyone else affected,

Accepted docker.io into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/docker.io/20.10.7-0ubuntu4~21.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Paride, or anyone else affected,

Accepted docker.io into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/docker.io/20.10.7-0ubuntu4~20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted docker.io (20.10.7-0ubuntu4~21.04.1) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

golang-github-containers-image/5.10.3-1ubuntu1 (ppc64el, arm64, s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#docker.io

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Tomáš Virtus (virtustom)]

Successfully tested docker.io on hirsute.

With docker.io 20.10.7-0ubuntu1~21.04.2 from hirsute:

$ sudo docker run ubuntu:impish apt-get remove -qqqq --allow-remove-essential e2fsprogs
(Reading database ... 4386 files and directories currently installed.)
Removing e2fsprogs (1.46.3-1ubuntu3) ...
E: Problem executing scripts DPkg::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true'
E: Sub-process returned an error code
$ echo $?
100

With docker.io 20.10.7-0ubuntu4~21.04.1 from hirsute-proposed:

$ sudo docker run ubuntu:impish apt-get remove -qqqq --allow-remove-essential e2fsprogs
(Reading database ... 4386 files and directories currently installed.)
Removing e2fsprogs (1.46.3-1ubuntu3) ...
$ echo $?
0

[Thomas Weise (tweise)]

Hi.

First of all:
Sorry, I am probably reporting again(?) for the wrong issue(?)

I have fully updated my ubuntu (see all the version information in the command output print below).
However, my problem mentioned in https://bugs.launchpad.net/cloud-images/+bug/1943049/comments/43 still persists:
I cannot install curl with &&-chained commands (and if I install it without using the &&-chain, it fails to access an url).
Therefore, I cannot use curl to access a website (see https://bugs.launchpad.net/cloud-images/+bug/1943293, marked as duplicate of the problem in this thread).
(Therefore, git on a https repo would not work either.)

As said, I am not sure whether the new release or fix was supposed to solve this problem or whether I am commenting on a wrong topic.
Nevertheless, here is the current state of my problem:

1. The chain "apt-get update && apt-get install -y curl" will fail.
I think concatenating these commands with "&&" may be common in a docker build, therefore this may still be considered as an issue.

2. "apt-get install -y curl" alone (separately, after the update) does install curl, though, while printing some error message.

3. "curl https://bing.com" still fails with "curl: (6) getaddrinfo() thread failed to start", which was my originally reported problem in https://bugs.launchpad.net/cloud-images/+bug/1943293.

Addendum/Update:
A. I noticed just now that I overlooked the mentioning of https://wiki.ubuntu.com/Testing/EnableProposed in a prior post, i.e., I ran the test on my "normal" ubuntu. Sorry for that.
B. Some of this post here seems to be cut-off but is downloadable in the "Download full text" link at the top.

Below, please find the complete command chain and output:

$ docker --version
Docker version 20.10.7, build 20.10.7-0ubuntu1~21.04.2

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 21.04
Release: 21.04
Codename: hirsute

$ uname -a
Linux laptop 5.11.0-37-generic #41-Ubuntu SMP Mon Sep 20 16:39:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ sudo docker run --rm -it --entrypoint=/bin/bash "ubuntu:21.10"
Unable to find image 'ubuntu:21.10' locally
21.10: Pulling from library/ubuntu
6122078cc60f: Pull complete
Digest: sha256:203d16099ec9f0529f1fd6e7f33cef02fc637bfae1d9d5721f733e59d4d90bad
Status: Downloaded newer image for ubuntu:21.10

root@5ec4cc137ca7:/# uname -a
Linux 5ec4cc137ca7 5.11.0-37-generic #41-Ubuntu SMP Mon Sep 20 16:39:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

root@5ec4cc137ca7:/# apt-get update && apt-get install -y curl
Get:1 http://security.ubuntu.com/ubuntu impish-security InRelease [90.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu impish InRelease [269 kB]
Get:3 http://archive.ubuntu.com/ubuntu impish-updates InRelease [90.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu impish-backports InRelease [90.7 kB]
Get:5 http://archive.ubuntu.com/ubuntu impish/multiverse amd64 Packages [255 kB]
Get:6 http://archive.ubuntu.com/ubuntu impish/restricted amd64 Packages [119 kB]
Get:7 http://archive.ubuntu.com/ubuntu impish/universe amd64 Packages [16.7 MB]
Get:8 http://archive.ubuntu.com/ubuntu impish/main amd64 Packages [1809 kB] ...

[Clément Peron (peron-clem)]

Hi,

The bug is explained here:
https://pascalroeleven.nl/2021/09/09/ubuntu-21-10-and-fedora-35-in-docker/

Regards,
Clement

[Lucas Kanashiro (lucaskanashiro)]

Hi Thomas,

Thanks for all the testing. The version you are using does not contain the fix, if you check the changelog of version 20.10.7-0ubuntu1~21.04.2 you will see that this is a security fixes (coming from the security pocket). This happened because an important CVE came up and we needed to fix it ASAP, I did apply the fix of this bug on top of this security fix but it is still waiting for the SRU team. For more info on the backporting check out this bug:

https://bugs.launchpad.net/ubuntu/+source/runc/+bug/1938908

In Hirsute, this is the version we need to land to fix this bug:

https://launchpad.net/ubuntu/+source/docker.io/20.10.7-0ubuntu4~21.04.1

You can also keep an eye on this page for more info about SRUs:

https://people.canonical.com/~ubuntu-archive/pending-sru.html

[Steve Langasek (vorlon)]

Hello Paride, or anyone else affected,

Accepted docker.io into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/docker.io/20.10.7-0ubuntu5~21.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Paride, or anyone else affected,

Accepted docker.io into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/docker.io/20.10.7-0ubuntu5~20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted docker.io (20.10.7-0ubuntu4~21.04.1) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

golang-github-containers-image/5.10.3-1ubuntu1 (ppc64el, s390x, arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#docker.io

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted docker.io (20.10.7-0ubuntu5~20.04.1) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

docker.io/20.10.7-0ubuntu5~20.04.1 (arm64, s390x, ppc64el, amd64)
ubuntu-fan/0.12.13 (arm64, s390x, ppc64el, amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#docker.io

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted docker.io (20.10.7-0ubuntu5~21.04.1) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

docker.io/20.10.7-0ubuntu5~21.04.1 (ppc64el, arm64, s390x, amd64)
golang-github-containers-image/5.10.3-1ubuntu1 (ppc64el, arm64, s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#docker.io

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[atom (adamcstephens)]

I've tested 20.10.7-0ubuntu5~20.04.1 on focal and it resolves this issue for me.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Steve Langasek (vorlon)]

Hello Paride, or anyone else affected,

Accepted containerd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/containerd/1.5.5-0ubuntu3~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Paride, or anyone else affected,

Accepted containerd into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/containerd/1.5.5-0ubuntu3~21.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Paride, or anyone else affected,

Accepted containerd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/containerd/1.5.5-0ubuntu3~20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted containerd (1.5.5-0ubuntu3~18.04.1) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

docker.io/20.10.7-0ubuntu1~18.04.2 (amd64, i386, arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#containerd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Steve Langasek (vorlon)]

Hello Paride, or anyone else affected,

Accepted docker.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/docker.io/20.10.7-0ubuntu5~18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted containerd (1.5.5-0ubuntu3~20.04.1) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

containerd/1.5.5-0ubuntu3~20.04.1 (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#containerd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted docker.io (20.10.7-0ubuntu5~18.04.1) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

docker.io/20.10.7-0ubuntu5~18.04.1 (arm64, i386)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#docker.io

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Steve Langasek (vorlon)]

Hello Paride, or anyone else affected,

Accepted docker.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/docker.io/20.10.7-0ubuntu5~18.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted docker.io (20.10.7-0ubuntu5~18.04.2) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

ubuntu-fan/0.12.10 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#docker.io

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Lucas Kanashiro (lucaskanashiro)]

Verification:

===== Hirsute =====

ubuntu@hirsute:~$ dpkg -l | grep docker.io
ii docker.io 20.10.7-0ubuntu5~21.04.1 amd64 Linux container runtime
ubuntu@hirsute:~$ sudo docker run -it --rm ubuntu:impish /bin/bash -c 'apt-get update; apt-get full-upgrade -y; apt-get install -y jq'
Unable to find image 'ubuntu:impish' locally
impish: Pulling from library/ubuntu
3910f09893e5: Pull complete
Digest: sha256:f53c26896aaebc7727f3255c24e261b1b6f630a848a2e67c8cc5848d7c33f93f
Status: Downloaded newer image for ubuntu:impish
Get:1 http://security.ubuntu.com/ubuntu impish-security InRelease [99.5 kB]
Get:2 http://archive.ubuntu.com/ubuntu impish InRelease [270 kB]
Get:3 http://security.ubuntu.com/ubuntu impish-security/universe amd64 Packages [5466 B]
Get:4 http://security.ubuntu.com/ubuntu impish-security/main amd64 Packages [7654 B]
Get:5 http://archive.ubuntu.com/ubuntu impish-updates InRelease [99.8 kB]
Get:6 http://archive.ubuntu.com/ubuntu impish-backports InRelease [90.7 kB]
Get:7 http://archive.ubuntu.com/ubuntu impish/main amd64 Packages [1793 kB]
Get:8 http://archive.ubuntu.com/ubuntu impish/universe amd64 Packages [16.7 MB]
Get:9 http://archive.ubuntu.com/ubuntu impish/multiverse amd64 Packages [256 kB]
Get:10 http://archive.ubuntu.com/ubuntu impish/restricted amd64 Packages [110 kB]
Get:11 http://archive.ubuntu.com/ubuntu impish-updates/main amd64 Packages [25.9 kB]
Get:12 http://archive.ubuntu.com/ubuntu impish-updates/restricted amd64 Packages [21.6 kB]
Get:13 http://archive.ubuntu.com/ubuntu impish-updates/universe amd64 Packages [5911 B]
Fetched 19.5 MB in 4s (4374 kB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libjq1 libonig5
The following NEW packages will be installed:
  jq libjq1 libonig5
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 359 kB of archives.
After this operation, 1083 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu impish/main amd64 libonig5 amd64 6.9.6-1.1build1 [174 kB]
Get:2 http://archive.ubuntu.com/ubuntu impish/main amd64 libjq1 amd64 1.6-2.1ubuntu2 [133 kB]
Get:3 http://archive.ubuntu.com/ubuntu impish/main amd64 jq amd64 1.6-2.1ubuntu2 [52.5 kB]
Fetched 359 kB in 1s (247 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libonig5:amd64.
(Reading database ... 4386 files and directories currently installed.)
Preparing to unpack .../libonig5_6.9.6-1.1build1_amd64.deb ...
Unpacking libonig5:amd64 (6.9.6-1.1build1) ...
Selecting previously unselected package libjq1:amd64.
Preparing to unpack .../libjq1_1.6-2.1ubuntu2_amd64.deb ...
Unpacking libjq1:amd64 (1.6-2.1ubuntu2) ...
Selecting previously unselected package jq.
Preparing to unpack .../jq_1.6-2.1ubuntu2_amd...

[Launchpad Janitor (janitor)]

This bug was fixed in the package containerd - 1.5.5-0ubuntu3~21.04.1

---------------
containerd (1.5.5-0ubuntu3~21.04.1) hirsute; urgency=medium

  * Backport version 1.5.5-0ubuntu3 from Impish (LP: #1938908).

containerd (1.5.5-0ubuntu3) impish; urgency=medium

  * SECURITY UPDATE: insufficiently restricted directory permissions
    - debian/patches/1.5-reduce-directory-permissions.patch: reduce
      permissions for bundle dir in runtime/v1/linux/bundle.go,
      runtime/v1/linux/bundle_test.go, runtime/v2/bundle.go,
      runtime/v2/bundle_default.go, runtime/v2/bundle_linux.go,
      runtime/v2/bundle_linux_test.go, runtime/v2/bundle_test.go,
      snapshots/btrfs/btrfs.go.
    - CVE-2021-41103

containerd (1.5.5-0ubuntu2) impish; urgency=medium

  * d/p/seccomp-support-clone3-syscall.patch: clone3 is explicitly requested
    to give ENOSYS instead of the default EPERM, when CAP_SYS_ADMIN is unset.
    (LP: #1943049).

 -- Lucas Kanashiro <email address hidden> Fri, 08 Oct 2021 11:37:00 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package docker.io - 20.10.7-0ubuntu5~21.04.1

---------------
docker.io (20.10.7-0ubuntu5~21.04.1) hirsute; urgency=medium

  * Backport version 20.10.7-0ubuntu5 from Impish (LP: #1938908).

docker.io (20.10.7-0ubuntu5) impish; urgency=medium

  [ Sergio Durigan Junior ]
  * d/t/docker-in-lxd:
    Improve dep8 test. Make it run a more complex test against an
    ubuntu:devel docker container, especially because glibc updates might
    break docker.io. Improve test reliability when running autopkgtest
    locally.

  [ Steve Beattie ]
  * SECURITY UPDATE: insufficiently restricted directory permissions
    - d/p/CVE-2021-41091.patch: Lock down docker root dir perms.
    - CVE-2021-41091
  * SECURITY UPDATE: permissions modifications outside of install directory
    - d/p/CVE-2021-41089.patch: chrootarchive: don't create parent dirs
      outside of chroot.
    - CVE-2021-41089

docker.io (20.10.7-0ubuntu4) impish; urgency=medium

  * d/p/seccomp-add-support-for-clone3-syscall-in-default-policy.patch: Fix
    failure with new glibc clone3 syscall adding it to the default seccomp
    policy (LP: #1943049).

 -- Lucas Kanashiro <email address hidden> Wed, 06 Oct 2021 10:41:32 -0300

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for containerd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package containerd - 1.5.5-0ubuntu3~20.04.1

---------------
containerd (1.5.5-0ubuntu3~20.04.1) focal; urgency=medium

  * Backport version 1.5.5-0ubuntu3 from Impish (LP: #1938908).
    - d/rules: set GO111MODULE to off, this avoid Internet connection during
      the build.

containerd (1.5.5-0ubuntu3) impish; urgency=medium

  * SECURITY UPDATE: insufficiently restricted directory permissions
    - debian/patches/1.5-reduce-directory-permissions.patch: reduce
      permissions for bundle dir in runtime/v1/linux/bundle.go,
      runtime/v1/linux/bundle_test.go, runtime/v2/bundle.go,
      runtime/v2/bundle_default.go, runtime/v2/bundle_linux.go,
      runtime/v2/bundle_linux_test.go, runtime/v2/bundle_test.go,
      snapshots/btrfs/btrfs.go.
    - CVE-2021-41103

containerd (1.5.5-0ubuntu2) impish; urgency=medium

  * d/p/seccomp-support-clone3-syscall.patch: clone3 is explicitly requested
    to give ENOSYS instead of the default EPERM, when CAP_SYS_ADMIN is unset.
    (LP: #1943049).

 -- Lucas Kanashiro <email address hidden> Fri, 08 Oct 2021 11:45:38 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package docker.io - 20.10.7-0ubuntu5~20.04.1

---------------
docker.io (20.10.7-0ubuntu5~20.04.1) focal; urgency=medium

  * Backport version 20.10.7-0ubuntu5 from Impish (LP: #1938908).

docker.io (20.10.7-0ubuntu5) impish; urgency=medium

  [ Sergio Durigan Junior ]
  * d/t/docker-in-lxd:
    Improve dep8 test. Make it run a more complex test against an
    ubuntu:devel docker container, especially because glibc updates might
    break docker.io. Improve test reliability when running autopkgtest
    locally.

  [ Steve Beattie ]
  * SECURITY UPDATE: insufficiently restricted directory permissions
    - d/p/CVE-2021-41091.patch: Lock down docker root dir perms.
    - CVE-2021-41091
  * SECURITY UPDATE: permissions modifications outside of install directory
    - d/p/CVE-2021-41089.patch: chrootarchive: don't create parent dirs
      outside of chroot.
    - CVE-2021-41089

docker.io (20.10.7-0ubuntu4) impish; urgency=medium

  * d/p/seccomp-add-support-for-clone3-syscall-in-default-policy.patch: Fix
    failure with new glibc clone3 syscall adding it to the default seccomp
    policy (LP: #1943049).

 -- Lucas Kanashiro <email address hidden> Wed, 06 Oct 2021 10:53:57 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package containerd - 1.5.5-0ubuntu3~18.04.1

---------------
containerd (1.5.5-0ubuntu3~18.04.1) bionic; urgency=medium

  * Backport version 1.5.5-0ubuntu3 from Impish (LP: #1938908).
    - d/control: do not b-d on libbtrfs-dev, it is not available in Bionic.
    - d/control: b-d on golang-1.13-go instead of golang-go.
    - d/rules: set GO111MODULE to off, to avoid Internet connection during the
      build.

containerd (1.5.5-0ubuntu3) impish; urgency=medium

  * SECURITY UPDATE: insufficiently restricted directory permissions
    - debian/patches/1.5-reduce-directory-permissions.patch: reduce
      permissions for bundle dir in runtime/v1/linux/bundle.go,
      runtime/v1/linux/bundle_test.go, runtime/v2/bundle.go,
      runtime/v2/bundle_default.go, runtime/v2/bundle_linux.go,
      runtime/v2/bundle_linux_test.go, runtime/v2/bundle_test.go,
      snapshots/btrfs/btrfs.go.
    - CVE-2021-41103

containerd (1.5.5-0ubuntu2) impish; urgency=medium

  * d/p/seccomp-support-clone3-syscall.patch: clone3 is explicitly requested
    to give ENOSYS instead of the default EPERM, when CAP_SYS_ADMIN is unset.
    (LP: #1943049).

 -- Lucas Kanashiro <email address hidden> Fri, 08 Oct 2021 11:55:12 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package docker.io - 20.10.7-0ubuntu5~18.04.2

---------------
docker.io (20.10.7-0ubuntu5~18.04.2) bionic; urgency=medium

  * d/t/control: make basic-smoke do not depend on debian-archive-keyring.
    In Bionic, when debian-archive-keyring is installed we are not able to
    debootstrap a Debian stable chroot. Removing this dependency make it
    work again.

docker.io (20.10.7-0ubuntu5~18.04.1) bionic; urgency=medium

  * Backport version 20.10.7-0ubuntu5 from Impish (LP: #1938908).
    - d/control: do not b-d on libbtrfs-dev, it is not available in Bionic.

docker.io (20.10.7-0ubuntu5) impish; urgency=medium

  [ Sergio Durigan Junior ]
  * d/t/docker-in-lxd:
    Improve dep8 test. Make it run a more complex test against an
    ubuntu:devel docker container, especially because glibc updates might
    break docker.io. Improve test reliability when running autopkgtest
    locally.

  [ Steve Beattie ]
  * SECURITY UPDATE: insufficiently restricted directory permissions
    - d/p/CVE-2021-41091.patch: Lock down docker root dir perms.
    - CVE-2021-41091
  * SECURITY UPDATE: permissions modifications outside of install directory
    - d/p/CVE-2021-41089.patch: chrootarchive: don't create parent dirs
      outside of chroot.
    - CVE-2021-41089

docker.io (20.10.7-0ubuntu4) impish; urgency=medium

  * d/p/seccomp-add-support-for-clone3-syscall-in-default-policy.patch: Fix
    failure with new glibc clone3 syscall adding it to the default seccomp
    policy (LP: #1943049).

 -- Lucas Kanashiro <email address hidden> Thu, 21 Oct 2021 16:55:00 -0300

[Vladimir Sergeev (wide0s)]

As of May 26th, I see this issue on ubuntu:jammy and ubuntu:22.04.

$ run -it --rm ubuntu:jammy bash -c "apt update"
Get:1 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB]
Get:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Get:3 http://security.ubuntu.com/ubuntu jammy-security/restricted amd64 Packages [156 kB]
Get:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [109 kB]
Get:5 http://security.ubuntu.com/ubuntu jammy-security/multiverse amd64 Packages [4653 B]
Get:6 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages [155 kB]
Get:7 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [99.8 kB]
Get:8 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 Packages [71.8 kB]
Get:9 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages [1792 kB]
Get:10 http://archive.ubuntu.com/ubuntu jammy/multiverse amd64 Packages [266 kB]
Get:11 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages [17.5 MB]
Get:12 http://archive.ubuntu.com/ubuntu jammy/restricted amd64 Packages [164 kB]
Get:13 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages [268 kB]
Get:14 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages [124 kB]
Get:15 http://archive.ubuntu.com/ubuntu jammy-updates/multiverse amd64 Packages [4653 B]
Get:16 http://archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 Packages [157 kB]
Get:17 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 Packages [1202 B]
Fetched 21.2 MB in 55s (387 kB/s)
Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke 'rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true'
E: Sub-process returned an error code

[Reinhard Tartler (siretart)]

@wide0s: what is the exact version of podman you were testing in the comment above? Please provide the output of:

type -p podman
dpkg -s podman
podman --version
podman system info

[Vladimir Sergeev (wide0s)]

@siretart: sorry, I've lost 'docker' while inserting the command. I don't have podman installed. The the command I used is: $ docker run -it --rm ubuntu:jammy bash -c "apt update"

The output of "docker --version" is "Docker version 20.10.8, build 3967b7d".

[Brian Murray (brian-murray)]

Ubuntu 21.10 (Impish Indri) has reached end of life, so this bug will not be fixed for that specific release.

[Alexander Adam (7ql6)]

Just to be sure: this will be fixed for 22.04 though, right?
Is there any workaround that can be used in the meantime?

[Michael Hudson-Doyle (mwhudson)]

I'm not sure what you mean. This is a poor interaction between the docker image being run and the docker that is running it. The fix is to upgrade the docker on the host side. We are not going to make changes to the 22.04 images to enable them to run with the buggy host docker versions.