46:"/_next/static/chunks/33yus346z0l_n.js" 47:"/_next/static/chunks/1r8ezocsukqp8.js" 48:"/_next/static/chunks/0iv56yrji_20j.js" 49:"/_next/static/chunks/0wa9m1-tphf9u.js" 4a:"/_next/static/chunks/08cuqqn_f60pp.js" 4b:"/_next/static/chunks/3zdsl3f9b0--r.js" 4c:"/_next/static/chunks/2j22cxchii_xx.js" 4d:"/_next/static/chunks/3bgoyiso1rhn7.js" 4e:"/_next/static/chunks/01a-3hvnqu8wl.js" 4f:"/_next/static/chunks/3m1xjj5kw5fie.js" 50:"/_next/static/chunks/0om3fkgfnicab.js" 51:"/_next/static/chunks/0gafyzg9j9yqj.js" 52:"/_next/static/chunks/20w4eaqlekefm.js" 53:"/_next/static/chunks/449--h5z1s6nq.js" 54:"/_next/static/chunks/3k2gyg36fnag_.js" 55:"/_next/static/chunks/18ggtgz2yf759.js" 56:"/_next/static/chunks/0hlb44ca7-4a2.js" 57:"/_next/static/chunks/253gnmj0-cj17.js" 58:"/_next/static/chunks/09nq57stwzkgf.js" 59:"/_next/static/chunks/082jo-0ajazgr.js" 5a:"/_next/static/chunks/2ozcrjb_hh74t.js" 5b:"/_next/static/chunks/05i8en-x14ibi.js" 5c:"/_next/static/chunks/32izpn90gvm22.js" 5d:"/_next/static/chunks/0jbzid2v9xv3h.js" 5e:"/_next/static/chunks/0i3-eynrkvqi7.js" 5f:"/_next/static/chunks/1tn-0fivsxsv1.js" 60:"/_next/static/chunks/34h36hyf_ggow.js" 61:"/_next/static/chunks/20329i6m_04t6.js" 62:"/_next/static/chunks/161uxd62cjny2.js" 63:"/_next/static/chunks/2k8pepwc4pxns.js" 64:I[593304,["$2b","$2c","$2d","$2e","$2f","$30","$46","$47","$48","$49","$4a","$4b","$4c","$4d","$4e","$4f","$50","$51","$52","$53","$54","$55","$56","$57","$58","$59","$5a","$5b","$5c","$5d","$5e","$5f","$60","$61","$62","$63"],"OwnedHydration"] 65:T42f,At its core, a **namespace** is a kernel mechanism that partitions system resources so that one set of processes sees one set of resources while another set of processes sees a different set. Each namespace type isolates a specific global system resource, creating the **illusion** that processes within the namespace have their own isolated instance of that resource. Consider how a traditional UNIX system works: all processes share a single view of the system. Every process sees the same process tree, the same network interfaces, the same mounted filesystems, the same hostname. This shared view is both powerful (enabling easy inter-process communication and resource sharing) and limiting (making true isolation impossible without heavyweight virtualization). Namespaces change this fundamental assumption. Instead of a single global namespace for each resource type, the kernel can maintain **multiple instances** of that namespace. Processes are assigned to specific namespace instances, and their view of the system is confined to what that namespace exposes.66:T498,**User Namespace (CLONE_NEWUSER)** The user namespace is perhaps the most powerful and complex. It isolates user and group IDs, enabling a process to have different UIDs inside and outside the namespace. A process can be root (UID 0) inside its user namespace while being an unprivileged user on the host. This capability enables: - Rootless containers (containers run by non-root users) - Improved security (container root has no host privileges) - Safe delegation of namespace creation to unprivileged users **Cgroup Namespace (CLONE_NEWCGROUP)** The cgroup namespace virtualizes the view of the cgroup hierarchy. A process in a cgroup namespace sees its current cgroup as the root of the hierarchy, rather than seeing the full host cgroup tree. This prevents containers from discovering information about other containers or the host through `/proc/self/cgroup`. **Time Namespace (CLONE_NEWTIME)** The newest addition, time namespaces allow processes to have different views of CLOCK_MONOTONIC and CLOCK_BOOTTIME. This enables scenarios like container migration (where boot time differs) and testing time-dependent applications without root access to set system time.67:T53e,#define _GNU_SOURCE #include #include #include #include #include static int child_func(void *arg) { // This child is now in: // - A new UTS namespace (can set its own hostname) // - A new PID namespace (sees itself as PID 1) // - A new mount namespace (mount ops are isolated) sethostname("container", 9); printf("Child PID (inside namespace): %d ", getpid()); // Will print: Child PID (inside namespace): 1 // Keep running to demonstrate isolation sleep(60); return 0; } int main() { char *stack = malloc(65536); // Create child in new namespaces int flags = CLONE_NEWUTS | // New UTS namespace CLONE_NEWPID | // New PID namespace CLONE_NEWNS | // New mount namespace SIGCHLD; // Send SIGCHLD on exit pid_t child_pid = clone(child_func, stack + 65536, // Stack grows downward flags, NULL); if (child_pid == -1) { perror("clone"); exit(1); } printf("Child PID (from parent's view): %d ", child_pid); // Will print: Child PID (from parent's view): waitpid(child_pid, NULL, 0); return 0; }68:T40b,**Persistent Namespaces (Bind-Mount Trick)** Sometimes you need a namespace to survive even when no processes are using it—for example, to prepare a network namespace before launching a container. This is achieved by **bind mounting** the namespace file: ```bash # Create a new network namespace without any process ip netns add my_namespace # This actually does: # 1. unshare(CLONE_NEWNET) in a helper process # 2. Bind mounts /proc/self/ns/net to /var/run/netns/my_namespace # 3. Helper process exits, but namespace persists due to bind mount ``` The bind mount holds a reference to the namespace object, preventing destruction even with zero processes. Removing the bind mount releases this reference. **File Descriptor References** Opening a namespace file (e.g., `open("/proc/1234/ns/net", O_RDONLY)`) also holds a reference. This is used by orchestrators to: - Hold namespaces while reconfiguring them - Pass namespace references between processes via socket SCM_RIGHTS - Inspect namespace properties without joining them45:["$","$L64",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792315444915,"state":{"data":{"json":{"id":"seed_5a271d393bdd504047f51a06f4660383","slug":"namespaces-and-cgroups","category":"Operating Systems","topic":"Namespaces and cgroups","title":"Linux Namespaces and Control Groups","description":"Master the fundamental Linux kernel primitives that enable containerization. Explore how namespaces provide process isolation across multiple system dimensions, and how cgroups enable precise resource control and limiting for process groups.","difficulty":"ADVANCED","estimatedMinutes":90,"pages":[{"id":"seed_3bff9d7a1b331a28fe14d2de64b968e9","title":"Linux Namespaces","order":0,"content":[{"id":"opening-hook","title":"The Foundation of Container Isolation","content":[{"data":{"content":"When Docker runs a container, or when Kubernetes orchestrates thousands of workloads across a cluster, the fundamental isolation that keeps each container's processes, filesystems, and network interfaces separate from the host and from each other comes from a surprisingly elegant kernel feature: **Linux namespaces**.\n\nNamespaces are not containers themselves—they are the **building blocks** from which containers are constructed. Understanding namespaces means understanding the atomic units of isolation that the Linux kernel provides, and how containerization technologies compose these primitives to create the sandboxed environments we rely on in modern infrastructure."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand what namespaces are, why they exist, the historical context that led to their development, the different types of namespaces Linux provides, and how the kernel implements namespace isolation at the process level. You will gain the foundational knowledge required to understand containerization from first principles.","variant":"info"},"type":"callout"}]},{"id":"namespace-concept","title":"The Namespace Concept","content":[{"data":{"content":"$65"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Namespace Abstraction","content":"Think of namespaces as creating parallel universes within the kernel. Each universe has its own version of certain system resources. Processes living in one universe cannot see or affect processes in another universe—from their perspective, their universe *is* the entire system.","variant":"tip"},"type":"callout"},{"data":{"content":"**Key properties of namespaces:**\n\n1. **Isolation**: Processes in different instances of a namespace cannot see each other's resources for that namespace type\n2. **Hierarchical**: Namespaces can form hierarchies, with parent namespaces having visibility into child namespaces but not vice versa\n3. **Composable**: A process belongs to exactly one instance of each namespace type, and different namespace types operate independently\n4. **Lightweight**: Unlike full virtualization, namespaces are implemented within the same kernel and share most kernel data structures, making them extremely efficient\n5. **Progressive adoption**: New processes inherit their parent's namespace memberships by default, but can be moved to new namespaces at creation time or, for some types, during execution"},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"historical-context","title":"Historical Context and Evolution","content":[{"data":{"content":"Linux namespaces did not emerge fully formed. They evolved over nearly two decades, with each namespace type addressing specific isolation requirements that became apparent as the industry's understanding of containerization matured.\n\n**The Pre-Namespace Era (Before 2002)**\n\nBefore namespaces, process isolation on Linux was limited to traditional UNIX mechanisms:\n- **Users and groups**: Basic access control but no visibility isolation\n- **chroot**: Filesystem isolation, but easily escapable and incomplete\n- **Separate machines**: True isolation required dedicated hardware or heavyweight VMs\n\nThe need for lightweight isolation became pressing as hosting providers sought better multi-tenancy, and as security researchers demonstrated the limitations of chroot for containment."},"type":"text"},{"data":{"rows":[["2002","2.4.19","Mount (mnt)","Filesystem isolation, extending chroot concept"],["2006","2.6.19","UTS","Hostname and domain name isolation"],["2006","2.6.19","IPC","System V IPC and POSIX message queue isolation"],["2006","2.6.24","PID","Process ID isolation, virtualized PID trees"],["2009","2.6.29","Network (net)","Network stack isolation, virtual interfaces"],["2013","3.8","User","User and group ID mapping isolation"],["2016","4.6","Cgroup","Control group hierarchy isolation"],["2020","5.6","Time","System time virtualization (per-namespace clocks)"]],"caption":"Timeline of Linux Namespace Evolution","headers":["Year","Kernel Version","Namespace Type","Purpose"]},"type":"table"},{"data":{"content":"**The mount namespace (2002)** was the first, introduced as an extension to the Plan 9 operating system's concept of per-process filesystem views. It allowed different processes to see different filesystem layouts—a powerful extension to chroot that couldn't be circumvented by simply navigating directory structures.\n\n**The containerization wave (2006-2009)** brought rapid development. The UTS, IPC, and PID namespaces emerged as researchers at IBM and other organizations worked on container technologies like OpenVZ and later LXC. Network namespaces completed the picture for practical containerization.\n\n**User namespaces (2013)** represented a paradigm shift—they enabled unprivileged users to create and administer containers by mapping UID/GID ranges, fundamentally changing the security model.\n\n**Recent additions (2016-2020)** reflect ongoing refinement. Cgroup namespaces improve container nesting, while time namespaces enable scenarios requiring time manipulation without host privileges."},"type":"text"},{"data":{"icon":"Info","title":"Ongoing Development","content":"Namespace development continues. Proposals for additional namespace types (such as syslog namespaces) are regularly discussed in the Linux kernel community. The architecture is intentionally extensible, allowing new isolation boundaries to be added as requirements emerge.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"namespace-types","title":"The Eight Namespace Types","content":[{"data":{"content":"Modern Linux (kernel 5.6+) supports eight distinct namespace types, each isolating a specific system resource. Understanding each type is essential for comprehending how containers achieve comprehensive isolation.\n\n**Mount Namespace (CLONE_NEWNS)**\n\nThe mount namespace isolates the set of filesystem mount points seen by processes. When a process is in its own mount namespace, mounting or unmounting filesystems affects only processes in that namespace—the host and other containers remain unaffected.\n\nThis is foundational for containers: it enables each container to have its own root filesystem, with its own `/proc`, `/sys`, and any other mount points, completely independent of the host's mount table."},"type":"text"},{"data":{"items":["**Independent mount trees** — Each namespace has its own /proc/mounts","**Mount propagation control** — Shared, slave, private, and unbindable propagation modes","**Filesystem overlay** — OverlayFS and bind mounts for image layering","**Security boundary** — Prevents container mount operations from affecting host"],"title":{"icon":"Target","text":"Mount Namespace Capabilities","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**UTS Namespace (CLONE_NEWUTS)**\n\nNamed after the 'UNIX Time-sharing System', the UTS namespace isolates the system's hostname and NIS (Network Information Service) domain name. Each UTS namespace has its own `hostname` and `domainname`, allowing containers to have distinct identities without affecting each other or the host.\n\nWhile seemingly simple, hostname isolation is critical for applications that use hostname for identity, logging, and service discovery.\n\n**IPC Namespace (CLONE_NEWIPC)**\n\nThe IPC namespace isolates System V IPC objects (semaphores, message queues, shared memory segments) and POSIX message queues. Processes in different IPC namespaces cannot access each other's IPC resources, even if they know the identifiers.\n\nThis prevents information leakage between containers through IPC channels and ensures that IPC identifier collisions between containers cannot occur."},"type":"text"},{"data":{"content":"**PID Namespace (CLONE_NEWPID)**\n\nThe PID namespace virtualizes process IDs. Each PID namespace has its own independent set of PIDs starting from 1. The first process in a new PID namespace becomes PID 1 within that namespace—the init process for that container.\n\nCritically, PID namespaces are **hierarchical**. A process is visible in its own PID namespace and all ancestor namespaces (with different PIDs in each). This allows the host to manage container processes while containers cannot see or signal processes outside their namespace.\n\n**Network Namespace (CLONE_NEWNET)**\n\nThe network namespace provides complete network stack isolation. Each network namespace has its own:\n- Network devices (eth0, lo, etc.)\n- IP addresses and routing tables\n- Port numbers (two containers can both bind to port 80)\n- Firewall rules (iptables/nftables)\n- `/proc/net` contents\n\nVirtual ethernet pairs (veth) connect namespaces, enabling controlled network communication between containers and with the host."},"type":"text"},{"data":{"content":"$66"},"type":"text"},{"data":{"rows":[["Mount","CLONE_NEWNS","Filesystem mount points","Container root filesystem"],["UTS","CLONE_NEWUTS","Hostname, domain name","Container identity"],["IPC","CLONE_NEWIPC","IPC objects, message queues","IPC isolation"],["PID","CLONE_NEWPID","Process IDs","Process tree isolation"],["Network","CLONE_NEWNET","Network stack","Network isolation"],["User","CLONE_NEWUSER","User/Group IDs","Privilege separation"],["Cgroup","CLONE_NEWCGROUP","Cgroup hierarchy view","Container nesting"],["Time","CLONE_NEWTIME","System clocks","Time virtualization"]],"caption":"Namespace Types Summary","headers":["Namespace","Clone Flag","Isolates","Primary Use Case"]},"type":"table"}],"titleType":"number","titleNumber":3},{"id":"kernel-implementation","title":"Kernel Implementation Architecture","content":[{"data":{"content":"Understanding how the kernel implements namespaces illuminates both their power and their limitations. The implementation is remarkably elegant, built around a few key data structures and system calls.\n\n**The nsproxy Structure**\n\nAt the heart of namespace implementation is the `nsproxy` structure. Every process (represented by a `task_struct`) has a pointer to an `nsproxy`, which in turn contains pointers to the actual namespace objects the process belongs to."},"type":"text"},{"data":{"code":"struct nsproxy {\n atomic_t count; // Reference count\n struct uts_namespace *uts_ns; // UTS namespace\n struct ipc_namespace *ipc_ns; // IPC namespace \n struct mnt_namespace *mnt_ns; // Mount namespace\n struct pid_namespace *pid_ns_for_children; // PID namespace for children\n struct net *net_ns; // Network namespace\n struct time_namespace *time_ns; // Time namespace\n struct time_namespace *time_ns_for_children;\n struct cgroup_namespace *cgroup_ns; // Cgroup namespace\n};","fileName":"kernel/nsproxy.h (simplified)","languages":[{"label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Reference counting** ensures namespaces persist as long as any process uses them. When the last process exits a namespace (and no external references remain, such as bind-mounted namespace files), the namespace is destroyed and its resources released.\n\n**Namespace inheritance** works through the `nsproxy`. When a process forks, the child typically shares the parent's `nsproxy`—both point to the same namespace instances. Only when a process explicitly creates a new namespace (via `clone()` or `unshare()`) does the kernel allocate a new namespace object and potentially a new `nsproxy`.\n\n**The User Namespace Exception**\n\nNotice that `user_namespace` is not in `nsproxy`. Instead, it's stored directly in the process's credentials (`struct cred`). This reflects user namespaces' special role in the permission model—they affect privilege checks throughout the kernel, not just resource visibility."},"type":"text"},{"data":{"icon":"AlertCircle","title":"User Namespace Ownership","content":"Every namespace (except user namespaces themselves) is owned by a user namespace. This ownership determines which user namespace's privilege rules apply when operating on that namespace. A process with CAP_SYS_ADMIN in the user namespace that owns a mount namespace can mount filesystems in that mount namespace, even if it lacks that capability in other user namespaces.","variant":"warning"},"type":"callout"},{"data":{"content":"**Namespace Objects**\n\nEach namespace type has its own kernel structure containing the isolated resources. For example:\n\n- `struct pid_namespace` contains the PID allocation bitmap, init process pointer, and link to parent PID namespace\n- `struct net` contains routing tables, netfilter rules, and network device lists\n- `struct mnt_namespace` contains the mount tree root and mount ID allocator\n\nThese structures are created during namespace creation and populated with either empty/default resources (for truly new namespaces) or copies of the parent's resources (for most namespace types).\n\n**The Namespace Filesystem (/proc/[pid]/ns/)**\n\nThe kernel exposes namespace membership through a special filesystem. For each process, `/proc/[pid]/ns/` contains symbolic links representing the namespaces that process belongs to. These links have several remarkable properties:"},"type":"text"},{"data":{"items":["**Unique inode per namespace** — Each namespace instance has a unique inode number, enabling comparison (same inode = same namespace)","**Bind mountable** — Can be bind-mounted elsewhere, keeping the namespace alive even without processes","**Openable** — Opening the file gives a file descriptor that can be passed to setns() to join that namespace","**Magic symlink** — The link target format (e.g., `net:[4026531840]`) encodes the namespace type and inode"],"title":{"icon":"CheckCircle","text":"Namespace File Properties","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"titleType":"number","titleNumber":4},{"id":"system-calls","title":"System Calls for Namespace Operations","content":[{"data":{"content":"Three primary system calls govern namespace creation and manipulation: `clone()`, `unshare()`, and `setns()`. Understanding these is essential for anyone working with containers or implementing namespace-aware applications.\n\n**clone() — Create Process in New Namespaces**\n\nThe `clone()` system call creates a new process (like `fork()`) but with fine-grained control over what is shared between parent and child. Namespace flags determine which new namespaces the child should enter."},"type":"text"},{"data":{"code":"$67","fileName":"namespace-clone-example.c","languages":[{"label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**unshare() — Disassociate from Namespaces**\n\nThe `unshare()` system call allows an existing process to create new namespaces and move itself into them. This is useful when you want to isolate the current process rather than creating a new one."},"type":"text"},{"data":{"code":"#define _GNU_SOURCE\n#include \n#include \n#include \n\nint main() {\n printf(\"Before unshare - hostname: \");\n system(\"hostname\");\n \n // Create new UTS and mount namespaces for this process\n if (unshare(CLONE_NEWUTS | CLONE_NEWNS) == -1) {\n perror(\"unshare\");\n return 1;\n }\n \n // Now isolated - changing hostname only affects this process\n sethostname(\"isolated\", 8);\n printf(\"After unshare - hostname: \");\n system(\"hostname\"); // Prints: isolated\n \n // Parent shell still has original hostname!\n return 0;\n}","fileName":"namespace-unshare-example.c","languages":[{"label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**setns() — Join Existing Namespaces**\n\nThe `setns()` system call moves a process into an **existing** namespace, specified by a file descriptor. This is how tools like `docker exec` work—they open the namespace files of a running container and use `setns()` to join them."},"type":"text"},{"data":{"code":"#define _GNU_SOURCE\n#include \n#include \n#include \n#include \n\nint main(int argc, char *argv[]) {\n if (argc < 2) {\n printf(\"Usage: %s \n\", argv[0]);\n return 1;\n }\n \n char ns_path[256];\n int target_pid = atoi(argv[1]);\n \n // Open the target container's network namespace\n snprintf(ns_path, sizeof(ns_path), \n \"/proc/%d/ns/net\", target_pid);\n int ns_fd = open(ns_path, O_RDONLY);\n \n if (ns_fd == -1) {\n perror(\"open namespace\");\n return 1;\n }\n \n // Join the network namespace\n if (setns(ns_fd, CLONE_NEWNET) == -1) {\n perror(\"setns\");\n return 1;\n }\n \n close(ns_fd);\n \n // Now running in the container's network namespace\n // We see the container's network interfaces, routes, etc.\n execl(\"/bin/ip\", \"ip\", \"addr\", NULL);\n \n return 0;\n}","fileName":"namespace-setns-example.c","languages":[{"label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"The nsenter Command","content":"The `nsenter` utility wraps these system calls for command-line use. For example, `nsenter -t -n ip addr` joins the network namespace of process and runs `ip addr`. This is invaluable for debugging containers.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"namespace-lifecycle","title":"Namespace Lifecycle and Persistence","content":[{"data":{"content":"Namespaces have a defined lifecycle governed by reference counting. Understanding this lifecycle is crucial for implementing robust containerization and avoiding resource leaks.\n\n**Default Lifecycle (Process-Bound)**\n\nBy default, a namespace's lifetime is tied to the processes within it:\n\n1. **Creation**: A new namespace is created when a process calls `clone()` with namespace flags or `unshare()`\n2. **Usage**: The namespace exists while at least one process belongs to it\n3. **Destruction**: When the last process exits the namespace, the kernel destroys it and releases resources\n\nThis means that a container's namespaces naturally clean up when all container processes terminate—no explicit garbage collection needed."},"type":"text"},{"data":{"height":"350px","mermaidSyntax":"graph TD\n A[\"clone(CLONE_NEWPID)\"] --> B[\"New PID Namespace Created\"]\n B --> C{\"Processes in Namespace?\"}\n C -->|\"Yes\"| D[\"Namespace Active\"]\n D --> E[\"Process exits\"]\n E --> C\n C -->|\"No, but bind mount exists\"| F[\"Namespace Persisted\"]\n F --> G[\"Bind mount removed\"]\n G --> C\n C -->|\"No references\"| H[\"Namespace Destroyed\"]\n H --> I[\"Resources Released\"]\n"},"type":"mermaid-excalidraw"},{"data":{"content":"$68"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Namespace Resource Leaks","content":"Be careful when bind-mounting or holding file descriptors to namespaces. A forgotten bind mount will prevent namespace cleanup, leading to resource leaks. This is a common source of 'phantom' network interfaces or mount points that survive container deletion.","variant":"warning"},"type":"callout"},{"data":{"content":"**Orphaned Namespace Handling**\n\nPID namespaces have special destruction semantics. When the init process (PID 1) of a PID namespace dies, the kernel sends SIGKILL to all remaining processes in that namespace. This ensures containers are fully terminated when their init dies:\n\n1. Container init process (PID 1 inside, PID 12345 outside) crashes\n2. Kernel iterates through all processes in that PID namespace\n3. Each process receives SIGKILL\n4. Once all processes exit, the namespace is destroyed\n\nThis reaping behavior prevents orphaned zombie containers."},"type":"text"}],"titleType":"number","titleNumber":6},{"id":"security-considerations","title":"Security Considerations","content":[{"data":{"content":"Namespaces are a powerful security mechanism, but they have limitations and gotchas that practitioners must understand. Security depends on properly configuring multiple namespace types together, combined with other kernel features.\n\n**What Namespaces Protect Against**\n\nWhen properly configured, namespaces prevent containerized processes from:\n- Seeing host processes (PID namespace)\n- Accessing host network interfaces (network namespace)\n- Modifying host filesystem mounts (mount namespace)\n- Signaling host processes (PID namespace)\n- Using host IPC mechanisms (IPC namespace)\n- Binding to host ports (network namespace)"},"type":"text"},{"data":{"items":["**Shared namespaces**: Running containers with `--network=host` or `--pid=host` negates isolation for that resource type","**Privileged containers**: Using `--privileged` grants all capabilities and access to all host devices, defeating namespace isolation","**Excessive capabilities**: Capabilities like CAP_SYS_ADMIN can allow namespace escape depending on configuration","**Kernel vulnerabilities**: Namespaces are implemented in the kernel; kernel bugs can enable escapes","**/proc and /sys exposure**: Improperly mounted procfs/sysfs can leak host information or allow writes"],"title":{"icon":"AlertCircle","text":"Common Security Pitfalls","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**User Namespaces as a Security Boundary**\n\nUser namespaces fundamentally change the security model. Without user namespaces, UID 0 inside a container is UID 0 on the host—if they escape the container, they have root access. With user namespaces:\n\n- Container root (UID 0) maps to an unprivileged host user (e.g., UID 100000)\n- Kernel permission checks use the mapped UID\n- Escaping the container yields unprivileged host access\n\n**Capability Scoping**\n\nCapabilities (the split-up components of traditional root power) are scoped to namespaces. A process can have CAP_NET_ADMIN in its network namespace (allowing it to configure networking inside the container) without having that capability in the initial network namespace (preventing host network configuration).\n\nThis scoping enables fine-grained privilege delegation:\n- Grant CAP_SYS_ADMIN only within a user namespace\n- Allow mount operations only within a mount namespace\n- Permit network configuration only within a network namespace"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Namespaces Are Not Virtual Machines","content":"Containers share the host kernel. Kernel vulnerabilities can break namespace isolation. For strong security boundaries (e.g., multi-tenant cloud hosting), combine namespaces with additional layers: seccomp filters, AppArmor/SELinux profiles, or run containers inside lightweight VMs (like Kata Containers or Firecracker).","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-path-forward","title":"Summary: Linux Namespaces","content":[{"data":{"content":"We've covered substantial ground in understanding Linux namespaces. Let's consolidate the key takeaways:"},"type":"text"},{"data":{"type":"ordered","items":["**Namespaces are isolation primitives** — They partition global system resources so processes see isolated views of the system","**Eight namespace types exist** — Mount, UTS, IPC, PID, Network, User, Cgroup, and Time, each isolating a specific resource","**Namespaces are composable** — A process belongs to one instance of each namespace type; containers combine multiple namespaces","**Three system calls manage namespaces** — clone() creates processes in new namespaces, unshare() moves the current process, setns() joins existing namespaces","**Namespaces are reference-counted** — They persist while processes or bind mounts reference them, then are automatically destroyed","**User namespaces enable rootless containers** — UID mapping allows unprivileged users to create and administer isolated environments","**Security requires defense in depth** — Namespaces must be combined with capabilities, seccomp, and LSMs for robust isolation"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand the namespace concept and the eight namespace types at a high level, the next page dives deep into the three most critical namespaces for practical containerization: **PID namespaces**, **network namespaces**, and **mount namespaces**. We'll explore their internal mechanics, hierarchical structure, and how they interact to create the isolation that containers depend upon."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the foundational concept of Linux namespaces—the kernel primitive that enables containerization. You know the eight namespace types, how they're implemented in the kernel, and the system calls used to create and manage them. Next, we'll explore PID, network, and mount namespaces in depth.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_3b567377d4626706cce9eebd990c4872","title":"PID, Network, Mount Namespaces","order":1,"content":null,"isLocked":true},{"id":"seed_e0dfd33ba3849500a6ab1dbcc0f38931","title":"cgroups (Control Groups)","order":2,"content":null,"isLocked":true},{"id":"seed_ce6a824093b6b64e4511d1d5b8dcd461","title":"Resource Limiting","order":3,"content":null,"isLocked":true},{"id":"seed_daa2623629640c68751d693460ba72d0","title":"Container Isolation","order":4,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792315444833,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"namespaces-and-cgroups"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"namespaces-and-cgroups\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315444916,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315444913,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_5a271d393bdd504047f51a06f4660383"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_5a271d393bdd504047f51a06f4660383\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315444916,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315444915,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","get"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_3b567377d4626706cce9eebd990c4872"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_3b567377d4626706cce9eebd990c4872\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315444916,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315444915,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","getUserLike"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_3b567377d4626706cce9eebd990c4872"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_3b567377d4626706cce9eebd990c4872\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315444916,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792315444915,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["highlights","getHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_3b567377d4626706cce9eebd990c4872"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_3b567377d4626706cce9eebd990c4872\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315444916,"state":{"data":"$undefined","dataUpdateCount":0,"dataUpdatedAt":0,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"pending","fetchStatus":"fetching"},"queryKey":[["highlights","getPopularHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_3b567377d4626706cce9eebd990c4872","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_3b567377d4626706cce9eebd990c4872\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@69"}]},"children":"$L6a"}]