{
    "slug": "linux_namespaces",
    "term": "Linux Namespaces",
    "category": "linux",
    "difficulty": "advanced",
    "short": "Kernel feature that isolates global resources (PIDs, network, mounts, IPC, hostname, users) so processes see their own private view of the system.",
    "long": "Linux namespaces partition kernel resources so that a set of processes sees one instance of a resource while another set sees a different instance. They are the primary isolation primitive behind containers (Docker, Podman, LXC, Kubernetes pods) and are created via the clone(), unshare(), and setns() syscalls. Six classic namespace types each virtualize a different slice of global kernel state. PID namespace: gives processes their own PID number space; the first process becomes PID 1 and cannot see processes outside the namespace. Network (net) namespace: provides isolated network interfaces, routing tables, iptables rules, and sockets - veth pairs and bridges connect them. Mount (mnt) namespace: each namespace has its own mount table, so a bind mount or chroot in one container does not affect the host. IPC namespace: isolates System V IPC objects and POSIX message queues, preventing cross-container shared memory access. UTS namespace: isolates the hostname and domain name, letting each container call sethostname() without affecting peers. User namespace: maps UIDs and GIDs between the container and host, so root inside (UID 0) can be mapped to an unprivileged UID outside - the foundation of rootless containers. Newer additions include cgroup, time, and (pending) syslog namespaces. Namespaces compose with cgroups (which limit resource usage) and capabilities (which restrict privileged operations) to form the complete container sandbox. You can inspect a process's namespaces via /proc/<pid>/ns/, enter one with nsenter, or create them ad hoc with unshare(1). Understanding namespaces is essential for debugging container networking, building secure multi-tenant systems, and reasoning about why a process inside a container behaves differently from the same binary on the host.",
    "aliases": [
        "namespaces",
        "kernel namespaces",
        "container namespaces"
    ],
    "tags": [
        "linux",
        "containers",
        "isolation",
        "kernel",
        "namespaces"
    ],
    "misconception": "Namespaces provide full security isolation like virtual machines. In reality they only partition visibility of kernel resources - the kernel is still shared, so a kernel exploit or misconfigured capability can break out; real security needs namespaces plus user namespaces, seccomp, capabilities, and often AppArmor or SELinux.",
    "why_it_matters": "Every container runtime, sandboxed CI job, and rootless tool builds on namespaces; misunderstanding them leads to leaky isolation, broken networking between containers, and false confidence that a container boundary equals a security boundary.",
    "common_mistakes": [
        "Confusing namespaces (isolation) with cgroups (resource limits) - you need both for a real container.",
        "Assuming root inside a container is unprivileged on the host without enabling user namespaces.",
        "Forgetting that the network namespace starts with only a loopback interface and wondering why outbound traffic fails.",
        "Running unshare --pid without --fork --mount-proc, leaving /proc still showing host PIDs.",
        "Treating namespaces as a security boundary equivalent to a VM and skipping seccomp or capability hardening."
    ],
    "when_to_use": [],
    "avoid_when": [],
    "related": [
        "linux_cgroups",
        "linux_processes",
        "linux_user_management",
        "linux_file_permissions"
    ],
    "prerequisites": [
        "linux_processes",
        "linux_file_system",
        "linux_user_management"
    ],
    "refs": [
        "https://man7.org/linux/man-pages/man7/namespaces.7.html",
        "https://man7.org/linux/man-pages/man1/unshare.1.html",
        "https://lwn.net/Articles/531114/",
        "https://man7.org/linux/man-pages/man2/clone.2.html"
    ],
    "bad_code": "# Trying to isolate a process but leaking host state:\nunshare --pid bash\n# Inside: ps aux still shows ALL host processes!\n# Why? --pid alone creates the namespace but /proc is still the\n# host's procfs, and bash isn't PID 1 of the new namespace.\n\n# Same problem with networking:\nunshare --net bash\n# Inside: curl example.com -> fails, no interfaces, no DNS,\n# and no veth pair was created to reach the host network.",
    "good_code": "# Properly isolate PID, mount, and network namespaces:\nsudo unshare --pid --fork --mount-proc --uts --ipc --net bash\n\n# Inside the new shell:\nhostname container-a              # only changes UTS namespace\nps aux                            # sees only PID 1 (bash) and children\nip link                           # only 'lo', and it's down\nip link set lo up                 # bring loopback up\n\n# Inspect namespaces of a process from outside:\nls -l /proc/$(pgrep -f 'bash$')/ns/\n# lrwxrwxrwx ... net -> 'net:[4026532...]'\n# lrwxrwxrwx ... pid -> 'pid:[4026532...]'\n# lrwxrwxrwx ... mnt -> 'mnt:[4026532...]'\n\n# Enter an existing container's namespaces:\nsudo nsenter --target $(pgrep -f myapp) --net --pid --mount",
    "quick_fix": "Use unshare or nsenter to experiment: 'sudo unshare --pid --fork --mount-proc --net --uts --ipc bash' gives you a shell in fresh namespaces; inspect /proc/$$/ns/ to see the namespace IDs.",
    "severity": "info",
    "effort": "high",
    "created": "2026-05-22",
    "updated": "2026-05-22",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/linux_namespaces",
        "html_url": "https://codeclaritylab.com/glossary/linux_namespaces",
        "json_url": "https://codeclaritylab.com/glossary/linux_namespaces.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[Linux Namespaces](https://codeclaritylab.com/glossary/linux_namespaces) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/linux_namespaces"
            }
        }
    }
}