Ordering is the part that bites. cgroup membership is a property of the process, not of the namespace, so the write into /sys/fs/cgroup/mybundle/cgroup.procs has to land before you exec into the namespaced shell, or be done with the container's PID the moment unshare --fork returns it [12][13]. Get it backwards and you have a shell sitting in fresh namespaces under the host's limits, which behaves identically right up to the point where something allocates.
The /proc flag in that one-liner is doing more work than it looks like. A new PID namespace changes the numbering the kernel hands out, but ps reads /proc, and /proc is a mount. Without --mount-proc the process keeps the host's, and your PID 1 shell lists the host's process table [8]. That is the shape of most half-isolation bugs: namespaces isolate view, cgroups limit consumption [14], and the view can be correct in the kernel while the file the tool actually reads still points elsewhere.
On the filesystem, the walkthrough is honest about its own first draft. chroot relabels a path and leaves the process attached to the host's mount tree, and it is escapable [10]. pivot_root swaps the root mount outright, and after the lazy unmount and rmdir of /oldroot there is no path left to walk back out through, which is what runc does [11]. Both recipes are given. One of them is a boundary.
Count the namespaces in the unshare line and you get five: mount, uts, ipc, net and pid [1]. Nothing in it remaps user IDs, and every command in the post runs under sudo [17]. That makes it a sealed rootfs for a build you wrote, not a fence around code you did not.
What you do not get is reachability. The net namespace comes up with loopback and nothing else [9], and the supplied text stops at the sentence where it would have wired real connectivity [18]. For the locked-down runner case that is the live question, because a build that cannot fetch a dependency is not a build, and the rootfs itself is a tarball you have to have pulled already [5]. The offline half still works: a directory tree, five namespaces, a memory and process cap, and no registry or daemon involved [2].
That is also the argument for doing it by hand once. The author's framing is that this is the mental model for the OCI runtime spec, runc, crun, or a sandbox you write yourself [16], and the bundle directory you built is the same rootfs-plus-config layout the spec formalises [6]. It costs one tarball and a handful of commands to learn which pieces Docker assembles on your behalf [1], and which of them are already sitting on a machine where dockerd is not [4].
