"Docker" isn't at fault here either way, as Docker isn't its own "execution driver" (in Docker parlance) any more; that would be https://github.com/opencontainers/runc.
But to answer the spirit your question, each container runtime uses its own peculiar combination of such constructs. It's helpful to know that this attack allows you to break out of the combination used specifically by runc, and thereby to break out of any system relying on Docker (with the default runc execution driver.)
In Escaping Docker container using waitid() – CVE-2017-5123opencontainers
runc
Go2015–2026
opencontainers / runc
runc
CLI tool for spawning and running containers according to the OCI specification
42Distinct people
57Mentions
0Explicit recommenders
13.6KGitHub stars
What to know before exploring
What it is
CLI tool for spawning and running containers according to the OCI specification
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- moby/moby · linked in 2 of the same discussions
- opencontainers/runtime-spec · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:53 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year57 dated mentions
Observed mentions: 2015-06-22 18:01:36 UTC to 2026-10-23 10:01:24 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
runc
Introduction
runc is a CLI tool for spawning and running containers on Linux according to the OCI specification.
Releases
You can find official releases of runc on the release page.
All releases are signed by one of the keys listed in the runc.keyring file in the root of this repository.
Security
The reporting process and disclosure communications are outlined here.
Security Audit
A third party security audit was performed by Cure53, you can see the full report here.
Building
runc only supports Linux. See the header of go.mod for the minimally required Go version.
Pre-Requisites
Utilities and Libraries
In addition to Go, building runc requires multiple utilities and libraries to be installed on your system.
On Ubuntu/Debian, you can install the required dependencies with:
apt update && apt install -y make gcc linux-libc-dev libseccomp-dev pkg-config git
On CentOS/Fedora, you can install the required dependencies with:
yum install -y make gcc kernel-headers libseccomp-devel pkg-config git
On Alpine Linux, you can install the required dependencies with:
apk --update add bash make gcc libseccomp-dev musl-dev linux-headers git
The following dependencies are optional:
libseccomp - only required if you enable seccomp support; to disable, see Build Tags.
libpathrs - only required if you enable libpathrs support; to disable, see Build Tags.
For notes on installing libpathrs, see the next section.
libpathrs
libpathrs is a Rust library runc can optionally use for path safety. As
mentioned in the build tag section, its use is controlled with
the libpathrs build tag. runc currently requires at least libpathrs 0.2.5
in order to function properly.
At time of writing, very few distributions have libpathrs packages and so it is
usually necessary to build and install it locally. For detailed installation
instructions, see the upstream documentation, but for
development builds the following instructions should be sufficient:
libpathrs requires Rust 1.63+ (which is available on almost any distribution,
including Debian oldstable and enterprise distributions like RHEL or SLES).
Assuming you already have cargo installed (as well as other libpathrs
dependencies like clang and lld), the following steps are all that are
really necessary to install libpathrs:
LIBPATHRS_VERSION=0.2.5
curl -o - -sSL https://github.com/cyphar/libpathrs/releases/download/v${LIBPATHRS_VERSION}/libpathrs-${LIBPATHRS_VERSION}.tar.xz | tar xvfJ -
cd libpathrs-${LIBPATHRS_VERSION}/
make release
sudo ./install.sh --prefix=/usr/local
sudo ldconfig
As part of our CI, we make use of a custom installation script for
libpathrs which may be useful as a reference for
folks with more complicated needs. With script/build-libpathrs.sh the
installation of libpathrs becomes as simple as:
sudo ./script/build-libpathrs.sh "$LIBPATHRS_VERSION" /usr/local
sudo ldconfig
However, please note that this installation script is completely
unsupported and is not really intended for general use (it includes some
workarounds for issues in our CI which will no longer be necessary once
libpathrs has distribution packages we can use).
Build
# create a 'github.com/opencontainers' in your GOPATH/src
cd github.com/opencontainers
git clone https://github.com/opencontainers/runc
cd runc
make
sudo make install
You can also use go get to install to your GOPATH, assuming that you have a github.com parent folder already created under src:
go get github.com/opencontainers/runc
cd $GOPATH/src/github.com/opencontainers/runc
make
sudo make install
runc will be installed to /usr/local/sbin/runc on your system.
Version string customization
You can see the runc version by running runc --version. You can append a custom string to the
version using the EXTRA_VERSION make variable when building, e.g.:
make EXTRA_VERSION="+build-1"
Bear in mind to include some separator for readability.
Build Tags
runc supports optional build tags for compiling support of various features,
with some of them enabled by default in the top-level Makefile.
The following build tags are currently recognized:
Build Tag
Feature
Set by Default
Dependencies
seccomp
Syscall filtering using libseccomp.
yes
libseccomp
libpathrs
Use libpathrs for path safety.
yes
libpathrs
runc_nocriu
Disables runc checkpoint/restore.
no
criu
To add or remove build tags from the default set, use the RUNC_BUILDTAGS
make or shell variable. Tags prefixed with - are removed from the default set;
others are added. For example:
# Add runc_nocriu and remove seccomp tag.
make RUNC_BUILDTAGS="runc_nocriu -seccomp"
The following build tags were used earlier, but are now obsoleted:
runc_nodmz (since runc v1.2.1 runc dmz binary is dropped)
nokmem (since runc v1.0.0-rc94 kernel memory settings are ignored)
apparmor (since runc v1.0.0-rc93 the feature is always enabled)
selinux (since runc v1.0.0-rc93 the feature is always enabled)
Running the test suite
runc currently supports running its test suite via Docker.
To run the suite just type make test.
make test
There are additional make targets for running the tests outside of a container but this is not recommended as the tests are written with the expectation that they can write and remove anywhere.
You can run a specific test case by setting the TESTFLAGS variable.
# make test TESTFLAGS="-run=SomeTestFunction"
You can run a specific integration test by setting the TESTPATH variable.
# make test TESTPATH="/checkpoint.bats"
You can run a specific rootless integration test by setting the ROOTLESS_TESTPATH variable.
# make test ROOTLESS_TESTPATH="/checkpoint.bats"
You can run a test using your container engine's flags by setting CONTAINER_ENGINE_BUILD_FLAGS and CONTAINER_ENGINE_RUN_FLAGS variables.
# make test CONTAINER_ENGINE_BUILD_FLAGS="--build-arg http_proxy=http://yourproxy/" CONTAINER_ENGINE_RUN_FLAGS="-e http_proxy=http://yourproxy/"
Go Dependencies Management
runc uses Go Modules for dependencies management.
Please refer to Go Modules for how to add or update
new
Read the full README on GitHubWhat Hacker News says
6 sourcesIt's important to note that if you want to use the blkio scheduler, if you're using the CFQ io scheduler[1] (which is the defualt on quite a lot of distributions) then using the blkio cgroup (even if you just join a non-root cgroup and don't have any limits set) can have massive performance penalties for O_DSYNC (and even some "regular") operations. It's caused by an implementation detail of blkio weighting within CFQ. We have a bug open in runc that details it[2].
Also, while this article is quite rosy-eyed about cgroupv2, there are many many issues that mean that cgroupv2 is not really usable by container runtimes today -- despite what systemd might be trying to do with their "hybrid mode". A friend of mine from the LXC community gave a talk about the wide variety of issues that occur due to cgroupv2's weirdly restrictive API[3]. The bl
Read the rest
kio writeback cache limits are very useful, but they're really not worth the pain of breaking how container runtimes have to work.
Also this comment is not _entirely_ accurate:
> Since in cgroups v1, different resources/controllers (memory, blkio) live in different hierarchies on the filesystem, even when those cgroups have the same name, they are completely independent. So, when the memory page is finally being flushed to disk, there is no way that the memory controller can know what blkio cgroup wrote that page.
You can mount a single cgroupv1 hierarchy with multiple controllers attached to it (that's what 'cpu,cpuset' are), which then could (in principle) know about it each other. But they don't, since a lot of the cgroupv2 code is locked behind cgroup_on_dfl(...) checks.
[1]: https://www.kernel.org/doc/Documentation/block/cfq-iosched.t...
[2]: https://github.com/opencontainers/runc/issues/861
[3]: https://www.youtube.com/watch?v=P6Xnm0IhiSo
> you still would prefer to be working entirely in C?
No, but there are more options than just Go and C. Rust is an option that I'm shilling at the moment (though I've only started learning it, so take that with a grain of salt). The main reason I would want to write it in C is because there's a lot of string parsing code you have to write in order to make container runtimes work -- and as we all know that's probably the #1 source of security vulnerabilities.
> Are there no advantages to Go for runc?
There are, mainly due to network effect (everything else is written in Go) and getting contributions from the community (Go is easy to pick up). Unfortunately there are also disadvantages, and quite a few of those disadvantages are present in Go but are not present in other memory-safe and low-level languages (Rust is a good example because t
Read the rest
o be quite honest it's the only player in this space that doesn't try to do more than necessary).
Go is a good language for it's designed for (Web servers and similar things), but from my experience it's not the best choice for low-level tasks. We've seen cases where long-running container daemons (not naming any names) will crash if you run more than 1000 containers on a single system. They don't crash because of the actual daemon code but because of issues with Go's GC (it doesn't actually free memory sanely, it uses MADV_DONTNEED which inflates RSS and causes OOM to kill your daemon).
> And, would it be possible for someone to write a somewhat standardized Go library for doing this grunt work?
Of course (and you could argue that we have done that in runc with github.com/opencontainers/runc/libcontainer/nsenter), but the thing to note is that in order to get around problems in the Go runtime you have to split out a single piece of code into separate processes and have to now redesign how a single function would work. So moving it to a separate library means that development is even more frustrating (you've created an API around the internal implementation of whatever thing you're working on).
> Is it merely fear of C that keeps so much of the container infrastructure on Go?
I think the network effect is the main reason. Most of the people I've worked with know quite a lot of C (we do kernel work sometimes) so writing a runtime in C would be frustrating but entirely doable. The problem is that you couldn't just import it into a Go project (and people don't like cgo because it makes binaries harder to build in certain cases).
> I've only spent a couple of weeks looking peripherally at Go, and I already like it better than C
Go definitely has it's uses, and I still use it for new projects. For example I recently wrote a tool for dealing with OCI container images in Go[1]. The standard library of Go is quite nice (though I found some bugs in archive/tar but let's not go there) and I'm always quite amazed just how much you can do before you have to import external libraries.
But I recently started learning Rust and I am _really_ enjoying being able to understand what my program will actually look like when compiled. If you've ever had to strace a Go program, you'll know exactly what I mean. Debugging Go programs is basically fucking impossible.
[1]: https://github.com/openSUSE/umoci
Docker uses this workaround: https://github.com/opencontainers/runc/tree/master/libcontai...
"The nsenter package registers a special init constructor that is called before the Go runtime has a chance to boot."
Kubernetes relies on CNI drivers which exit very soon after changing namespace; essentially they cross fingers and hope the problem won't strike.
In Linux Namespaces and Go Don't MixThere's a lot going on in this article, from a lot of different ends.
One of the big tensions (among many) that I'll focus on is rootless containers. Frankly it's a bit silly to think containers are useful when you need root on every system to use them- do people on academic systems simply not get the ability to use containers? As we move towards multi-tenant, "hyper-converged" systems (things running lots of workloads), figuring out who/what to bless as OK is a critical bottleneck, one that needs a lot of trust.
So the idea has been gesticulating around of "rootless" containers[1]. There's a lot of recent excitement and work- @lordcyphar has started a dedicated website for the idea, https://rootless.containe.rs [2], which gives a broad status overview of the pieces. The "runc" alternative to docker merged rootless recently, after a year
Read the rest
in progress[3], and recent work focuses- as the article hints at- around the filesystem side of things. He's building orca to build oci standard images, and although strongly hinted[4] I'm not sure how exactly that factors in to supporting rootless.
[1] https://www.cyphar.com/blog/post/rootless-containers-with-ru...
[2] https://rootlesscontaine.rs/
[3] https://github.com/opencontainers/runc/pull/774
[4] https://twitter.com/lordcyphar/status/849951277744181248
Rootless containers feature merged into runC
134 points · Open discussion