-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"operation not permitted", a libseccomp
story
#16829
Comments
To be explicitly clear: this is intended as an informational / reference issue, not a place to discuss more/related issues or as a place to ask for help. Any comments doing so will be hidden (and if it is a recurring problem, we will have to lock the issue, but we'd like to avoid doing that because it stops back-references from showing up here appropriately and those are useful). As a friendly reminder, if you need help (or are unsure whether this is "the issue" you're seeing), try a dedicated support forum such as the Docker Community Slack, Server Fault, Unix & Linux, or Stack Overflow. |
Container building still failing Add libseccomp-dev according to: docker-library/official-images#16829 to see if it gets fixed
This issue is to show example errors that happen when
dockerd
1 and/orlibseccomp[2]
2 are not up-to-date when using images based on a newer Linux distribution release.TL;DR:
libseccomp
lets you configure allowed syscalls for a process. Docker sets a default seccomp profile for all containers such that only certain syscalls are allowed and everything else is blocked (so, newer syscalls that are not yet known tolibseccomp
ordocker
are blocked3).libseccomp
by running the image with--security-opt seccomp=unconfined
libseccomp
anddocker
on the host running the containersswitch to an older image:
Many Docker Official Images have tags that reference the Linux distribution and some DOI support two concurrently. Check their Docker Hub description to see which tags are currently maintained.
for example, if
16
started failing when it moved to Debian Bookworm, then16-bullseye
is a valid workaround until the host can be updated. And similar for16-alpine
and16-alpine3.19
.One example is that, on some platforms,
tar -xzf file.tar.gz
usesfchmodat2
in Alpine 3.20 and fails. This syscall isn't in Docker's seccomp profile until Docker 26.0.0, 25.0.3, 24.0.10, and 23.0.10 (see moby/moby#47341 and linked backports).example:
other issues that are also a
libseccomp
denial:python:3.9
- Failed runapt update
from the last version of the image python#837related moby (docker) issue:
1
runc
andcontainerd
should be up-to-date as well but are usually included as a dependency when updating Docker (engine)2 might even require a newer
libseccomp[2]
package than your distribution/release currently includes, such as needing 2.5.5+ forfchmodat2
(#16830 (comment), https://bugs.debian.org/1071822)3 newer versions of
docker
and dependencies are being improved to block known syscalls (EPERM
), but newer syscalls should getENOSYS
: moby/moby#42871The text was updated successfully, but these errors were encountered: