runC

runC
Name	runC
Developer	Docker, Inc.; originally by LXC (Linux Containers) developers; maintained by the Open Container Initiative
Released	2014
Programming language	Go (programming language)
Operating system	Linux
License	Apache License

runC

runC is a lightweight, portable runtime for spawning and running containers on Linux systems. It provides a low-level, standards-compliant implementation of the OCI Runtime Specification, enabling projects such as Docker (software) and containerd to create and manage containerized processes. runC focuses on executing a single container instance with minimal dependencies, relying on kernel features like namespaces and cgroups provided by Linux kernel maintainers.

Overview

runC implements the runtime primitives required to create and run an isolated container environment on Linux. It exposes a command-line interface and library bindings used by higher-level container engines such as Docker (software), containerd, CRI-O, and orchestration systems like Kubernetes and Apache Mesos. As an OCI-conformant runtime, runC separates the concerns of image management—handled by projects like Docker Hub and CRI registry implementations—from process execution, which runC performs by interpreting an OCI Runtime Specification JSON bundle.

History and Development

runC originated within the ecosystem of LXC (Linux Containers) and the early Docker (software) project efforts around 2014, when containerization moved from collection of utilities into a modular architecture. The project was contributed to the newly formed Open Container Initiative (OCI) to create interoperable standards; runC became the reference implementation of the OCI runtime. Stewardship moved from proprietary development within Docker, Inc. to the community-governed OCI, with maintainers and contributors from organizations including Red Hat, Google, Microsoft, Amazon Web Services, IBM, and university research groups. Over time, runC evolved through releases addressing compatibility with evolving Linux kernel features, container image standards, and security hardening driven by the broader container ecosystem.

Architecture and Design

runC is designed as a thin, POSIX-friendly userland tool written in Go (programming language). It reads an OCI Runtime Specification bundle from disk—consisting of a config JSON and a filesystem bundle—and performs a sequence of kernel operations: creating namespaces such as PID, mount, IPC, UTS, and network via syscalls implemented in the Linux kernel, configuring resource limits via cgroups (control groups), performing filesystem mounts and pivot_root or MS_MOVE operations, setting up UID/GID mappings with user namespaces, and execve-ing the container process. The design intentionally keeps runC small and auditable, integrating with kernel features like seccomp filters and capabilities provided by Linux kernel developers. The codebase interacts with other projects such as runc-shim alternatives and runtime shims used by containerd and CRI-O to manage process lifecycles.

Usage and Command-line Interface

The runC command-line accepts subcommands to create, start, pause, kill, delete, and run containers based on OCI bundles. Typical workflows in orchestration systems call runC via API-level shims; developers and operators can invoke runC directly for debugging or bootstrapping container environments. Flags allow configuring console sockets, parent death signals, and debugging output. Integration patterns include use with image unpackers like Buildah, image registries such as Quay.io, and orchestration controllers like Kubernetes Controller Manager, which delegate low-level process management to runC through adapters like containerd-shim.

Security and Isolation Features

runC leverages core Linux kernel primitives to isolate container processes. It configures namespaces (PID, mount, network, IPC, UTS, user) to limit namespace visibility, employs cgroups (control groups) for resource isolation and accounting, and applies seccomp profiles to restrict syscall surfaces. runC supports user namespace UID/GID remapping to reduce privilege exposure and can drop capabilities to implement least privilege. Security hardening in runC has been influenced by vulnerability disclosures and mitigations involving kernel features, with collaboration among vendors like Red Hat, Google, Canonical, and security projects such as Project Atomic.

Integration and Ecosystem

runC sits at the base of a large container ecosystem. Higher-level runtimes and orchestrators—Docker (software), containerd, CRI-O, Kubernetes—invoke runC or its compatible implementations to execute containers. Image builders and distribution systems—Docker Hub, Harbor (software), Quay.io—supply filesystem bundles that runC executes. Monitoring, logging, and security tooling—Prometheus, Grafana, Falco (software), SELinux integrations—often observe or enforce policies at the runC-managed process boundary. Projects like podman and Buildah interact with runtime implementations to offer daemonless or rootless container workflows that may use runC or alternative OCI runtimes.

Criticisms and Incidents

runC, while intentionally minimal, has been subject to security disclosures and incidents typical for low-level runtime code interacting with complex kernel interfaces. High-profile vulnerabilities in the container supply chain and runtime interactions prompted coordinated disclosures and patches involving vendors like Docker, Inc., Red Hat, Google, and Amazon Web Services. Critics have pointed to the challenge of maintaining small trusted codebases while supporting diverse kernel versions and features; responses have included stricter auditing, fuzzing efforts by academic groups and companies, and diversification of runtimes with projects such as gVisor and kata-containers to provide alternative isolation models.

Category:Containerization software