Preface ​

In the previous article, we explored runc's defense-in-depth security model from SPEC.md, but left a core question unanswered: Why must CapPrm and CapEff be separate if they're both just collections of capabilities? And what's the difference between CapBnd and them?

To truly answer these questions, we first need to understand two prerequisite concepts: fork and exec. This article takes a zero-to-hero approach, driven by hands-on experiments, to demystify all five attributes of Linux Capabilities.

前言 ​

在 上一篇文章 中，我们从 runc 的 SPEC.md 了解了容器的纵深防御体系，留了一个核心问题没有展开：CapPrm 和 CapEff 既然都是 capability 集合，为什么必须分开？CapBnd 和它们有什么区别？

要真正理解这些问题，必须先搞清楚两个前置概念：fork 和 exec。本文从零开始，用实验驱动的方式，把 Capabilities 的五大属性讲透。

Preface ​

In the previous article, we completed the "Part 2" deconstruction of the Linux struct, diving deep into namespaces and identity mapping, kernel parameter tuning, filesystem masking, and the platform execution domain.

As promised at the end of that article, this final installment of the OCI Spec data structure series focuses on the two most complex and voluminous subsystems in all of config.go:

1. LinuxResources — The complete data mapping of Linux Cgroups v2 resource controllers
2. LinuxSeccomp — The intricate configuration structure for Linux system call filtering

These two subsystems form the bedrock of production container isolation. Understanding their data structure design is a prerequisite for understanding container resource guarantees and security hardening.

前言 ​

在上一篇文章中，我们完成了 Linux 结构体「中篇」的拆解，深入探讨了命名空间与身份映射、内核参数调优、文件系统掩蔽以及平台执行域等核心概念。

正如文末预告，本篇将是 OCI Spec 数据结构解析系列的最后一篇。我们将聚焦于整个 config.go 中最庞大、最复杂的两个子系统：

1. LinuxResources —— Linux Cgroups v2 资源控制器的完整数据映射
2. LinuxSeccomp —— Linux 系统调用过滤机制的精密配置结构

这两个子系统是生产环境容器隔离能力的根基，理解它们的数据结构设计是理解容器资源保障与安全加固的前提。

Introduction ​

In the previous article, we analyzed the container's top-level architecture Spec and the Process environment within the OCI specification. However, what truly gives Linux containers their isolation magic is the Linux field encapsulated within the Spec.

This Linux struct is arguably the core and the most technically profound part of the entire config.go. It perfectly maps the low-level features provided by the Linux kernel (Namespaces, Cgroups, Seccomp, Sysctls, etc.) into structured JSON data. This article focuses on dismantling this part to see how containers interface with Linux kernel features.

前言 ​

在上一篇文章中，我们解析了 OCI 规范中容器的顶层架构 Spec 和进程环境 Process。然而，真正让 Linux 容器具备隔离魔法的，是封装在 Spec 中的 Linux 字段。

这个 Linux 结构体可以说是整个 config.go 中最核心、最具技术深度的部分，它将 Linux 内核提供的底层特性（Namespaces, Cgroups, Seccomp, Sysctls 等）完美地映射为了结构化的 JSON 数据。本文将重点拆解这一部分，看看容器是如何与 Linux 内核特性对接的。

Introduction ​

In previous articles, we systematically analyzed container namespaces, filesystems, resource control (Cgroups and Intel RDT), and security defenses. Once all static configurations and isolated environments are prepared, the container startup enters the actual execution phase.

This article parses the Runtime and Init Process section in SPEC.md. This chapter specifies the inter-process synchronization mechanism during container creation, standard I/O handling, key files injected by the runtime, and the default parameter settings for the container process environment.