Advanced Types & Container Birth

IPC, User, Cgroup, Time namespaces — and how they combine to create a container

IPC Namespace — CLONE_NEWIPC

IPC namespaces isolate inter-process communication resources. Processes in different IPC namespaces cannot see or interact with each other's IPC objects.

          $ ipcs

          ------ Shared Memory Segments ------

          key        shmid  owner  perms  bytes

          0x00000000 0      root   644    80

          0x00000000 1      root   644    16384

          0x00000000 2      www    600    65536


          ------ Semaphore Arrays ------

          key        semid  owner  perms  nsems

          0x0052e2c1 0      postgres 600  17
        

          $ ipcs

          ------ Shared Memory Segments ------

          key        shmid  owner  perms  bytes


          ------ Semaphore Arrays ------

          key        semid  owner  perms  nsems


          # Empty! Container can't see

          # host IPC objects
        

User Namespace — CLONE_NEWUSER (the game-changer)

User namespaces are the most security-critical namespace type. They enable UID/GID remapping: a process can appear to be root (UID 0) inside the namespace while actually running as an unprivileged user (e.g., UID 100000) on the host.

The Mapping Files

UID and GID mappings are defined in /proc/[pid]/uid_map and /proc/[pid]/gid_map. The format is:

# Format: <inside-start>  <outside-start>  <count>

# /proc/[pid]/uid_map
0    100000    65536
# UID 0 inside    = UID 100000 outside
# UID 1 inside    = UID 100001 outside
# ...up to 65536 UIDs mapped

# /proc/[pid]/gid_map — same format for GIDs
0    100000    65536

    # Check a container's UID mapping

    $ cat /proc/12345/uid_map

             0     100000      65536


    # Inside the container

    $ id

    uid=0(root) gid=0(root) groups=0(root)


    # But on the host, this process runs as UID 100000

    $ ps -o user,pid,comm -p 12345

    USER       PID COMMAND

    100000   12345 bash
  

Why This Is a Game-Changer: Rootless Containers

Security Properties

Cgroup Namespace — CLONE_NEWCGROUP (Linux 4.6, 2016)

Cgroup namespaces give a process a relative view of its cgroup hierarchy, hiding the host's cgroup tree structure.

          # Inside container, full path visible

          $ cat /proc/self/cgroup

          0::/system.slice/docker-abc123def456.scope


          # Container can see:

          #  - It's running under Docker

          #  - Its container ID

          #  - The host's cgroup hierarchy
        

          # Inside container, relative path

          $ cat /proc/self/cgroup

          0::/


          # Container sees / as its cgroup root

          # Can't navigate up to host cgroups

          # Can't discover other containers
        

Time Namespace — CLONE_NEWTIME (Linux 5.6, 2020)

The newest namespace type. It allows a container to have a different system uptime than the host by adding offsets to monotonic and boot-time clocks.

        # Offsets file for a process

        $ cat /proc/[pid]/timens_offsets

        monotonic  86400  0

        boottime   86400  0

        # 86400 seconds = 1 day offset

        # Container sees 1 day more uptime
      

All 8 Linux Namespace Types

How a Container Is Born — Putting It All Together

A container is not a kernel primitive — it's a combination of namespaces, cgroups, filesystem isolation, and security policies. Here's the exact sequence that a container runtime (like runc) follows:

1. clone() with ALL namespace flags

   Runtime calls clone() with CLONE_NEWNS | CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWIPC | CLONE_NEWUTS | CLONE_NEWUSER | CLONE_NEWCGROUP. The child process is now in fresh namespaces but still has the host's filesystem.

2. Child process is in new namespaces

   At this point the child can see its own PID as 1, has an empty network stack, a fresh IPC space, its own hostname — but the filesystem is still the host's.

3. Set up cgroups for resource limits

   The parent process places the child into a cgroup with configured limits: CPU shares/quota, memory limit, PIDs limit, block I/O weight. This happens via writing the child's PID to /sys/fs/cgroup/.../cgroup.procs.

4. pivot_root to the container's rootfs

   The container image (pulled from a registry) is unpacked to a directory. The child calls pivot_root() to make this directory the new root, then unmounts the old root. The host filesystem is no longer accessible.

5. Mount /proc, /sys, /dev inside the container

   Essential pseudo-filesystems are mounted: /proc (process info, respects PID NS), /sys (kernel/device info, read-only), /dev (device nodes, minimal set: null, zero, random, urandom, tty).

6. Set hostname (UTS NS)

   The container's hostname is set via sethostname(). This only affects the container's UTS namespace — the host hostname is untouched.

7. Configure networking (Net NS)

   A veth pair is created: one end goes into the container's network namespace, the other stays in the host (usually attached to a bridge like docker0 or cni0). IP addresses are assigned, routes are set up. In Kubernetes, this is where CNI plugins run (Calico, Cilium, Flannel).

8. Apply seccomp filters and drop capabilities

   A seccomp BPF profile is loaded to restrict which syscalls the process can make (e.g., block mount, reboot, kexec_load). Most Linux capabilities are dropped — only a minimal set like CAP_NET_BIND_SERVICE is retained.

9. exec() the container's entrypoint

   Finally, the child process calls execve() to replace itself with the container's entrypoint (e.g., /bin/sh, nginx, python app.py). This process becomes PID 1 in the container's PID namespace. The container is now running.

Visual: Container Lifecycle Flow

1. clone()

   New namespaces created

2. Cgroups

   Resource limits applied

3. pivot_root

   Rootfs from image

4. Mount /proc /sys

   Essential pseudo-fs

5. Network + Security

   veth, seccomp, caps

6. exec(entrypoint)

   Container is running

What a "Container" Actually Is

Practical: Creating a "Container" by Hand

To solidify the concept, here's how you'd manually create something container-like using just unshare and standard Linux tools:

    # Step 1: Create all namespaces (except network, which needs extra setup)

    $ sudo unshare --pid --mount --uts --ipc --fork bash



    # Step 2: Set a hostname (UTS namespace)

    $ hostname my-container

    $ hostname

    my-container



    # Step 3: Remount /proc for the new PID namespace

    $ mount -t proc proc /proc



    # Step 4: Verify isolation

    $ ps aux

    USER  PID %CPU %MEM   VSZ  RSS TTY STAT START TIME COMMAND

    root    1  0.0  0.0  7236 3968 pts/0 S 12:00 0:00 bash

    root    3  0.0  0.0 10072 3312 pts/0 R+ 12:00 0:00 ps aux



    $ ipcs

    ------ Shared Memory Segments ------

    (empty)



    # This is ~80% of what Docker does. Missing: rootfs,

    # network namespace + veth, cgroups, seccomp, user NS