← Back to results

ain menu move to sidebar hide Navigation Main page Contents Current events Random article About Wikipedia Contact us Contribute Help Learn to edit Community portal Recent changes Upload file Special pages Search Search Appearance Donate Create account Log in Personal tools Donate Create account Log in Contents move to sidebar hide (Top) 1 History 2 Namespace kinds Toggle Namespace kinds subsection 2.1 Mount (mnt) 2.2 Process ID (pid) 2.3 Network (net) 2.4 Inter-process Communication (ipc) 2.5 UTS 2.6 User ID (user) 2.7 Control group (cgroup) Namespace 2.8 Time 2.9 Proposed namespaces 2.9.1 syslog namespace 2.9.2 IMA namespace 3 Administrative hierarchy 4 Implementation details Toggle Implementation details subsection 4.1 Visibility in /proc 4.2 Syscalls 4.3 Destruction 5 Adoption 6 References 7 External links Toggle the table of contents Linux namespaces 5 languages Čeština Español Suomi Hrvatski Русский Edit links Article Talk English Read Edit View history Tools Tools move to sidebar hide Actions Read Edit View history General What links here Related changes Upload file Permanent link Page information Cite this page Get shortened URL Print/export Download as PDF Printable version In other projects Wikidata item Appearance move to sidebar hide From Wikipedia, the free encyclopedia Feature of the Linux kernel that partitions kernel resources For namespaces in general, see Namespace . namespaces Original author Al Viro Developers Eric W. Biederman, Pavel Emelyanov, Al Viro, Cyrill Gorcunov, Tejun Heo et al. Release 2002 &#59; 24 years ago  ( 2002 ) Written in C Operating system Linux Type System software License GPL and LGPL Namespaces are a feature of the Linux kernel that partition kernel resources such that one set of processes sees one set of resources, while another set of processes sees a different set of resources. The feature works by assigning the same namespace type to a set of resources and processes, but allowing those namespaces to refer to distinctly isolated environments. This provides the illusion that a process or a process group is the sole user of the system's hardware and software resources. Examples of such resources include process IDs , hostnames, user IDs, file names, network interfaces, and inter-process communication mechanisms. [ 1 ] [ 2 ] Linux namespaces, alongside cgroups (control groups), are the foundational technologies underpinning modern OS-level virtualization and containerization platforms such as Docker , Kubernetes , LXC , and Podman . While cgroups dictate how much of a system's resources a process can use (such as CPU, memory, and disk I/O limits), namespaces dictate what a process is allowed to see and interact with. The term "namespace" is often used to denote a specific type of namespace (e.g., process ID namespace) as well as for a particular space of names. A Linux system begins with a single initial namespace of each type, which is shared by all processes. Processes can subsequently create additional namespaces or join existing ones, allowing complex, nested isolation boundaries. History [ edit ] Linux namespaces were heavily inspired by the wider namespace functionality utilized throughout the Plan 9 from Bell Labs operating system, which treated everything as a file and provided per-process namespace isolation. [ 3 ] The Linux namespace implementation originated in 2002 with the release of the 2.4.19 kernel. The first namespace introduced was the mount namespace, pioneered by kernel developer Al Viro, which isolated filesystem mount points. [ 4 ] Because it was the first of its kind, the system call flag introduced for it was simply named CLONE_NEWNS (New Namespace), a name that does not specify "mount" and is often considered a historical artifact. Subsequent namespaces were introduced progressively over several years: UTS and IPC namespaces were added in kernel version 2.6.19 in 2006. PID namespaces were finalized in kernel 2.6.24 in 2008. Network namespaces were largely completed by kernel 2.6.29 in 2009. [ 5 ] User namespaces , primarily developed by Eric W. Biederman, were considered complete and functional in kernel version 3.8, released in 2013. [ 6 ] The introduction of user namespaces was a milestone, as it enabled the creation of "unprivileged containers"—containers that can run safely without requiring underlying superuser (root) privileges on the host system. [ 7 ] Cgroup namespaces were introduced in kernel 4.6 in March 2016, spearheaded by Tejun Heo. [ 8 ] Time namespaces were merged in kernel version 5.6 in March 2020, allowing containers to have their own monotonic and boot times. [ 9 ] Namespace kinds [ edit ] As of Linux kernel version 5.6, there are exactly eight kinds of namespaces. Namespace functionality operates uniformly across all kinds: each process is associated with a namespace and can only see or use the resources associated with that specific namespace, including its descendant namespaces where applicable. This provides each process (or group of processes) with a unique, compartmentalized view of the system. Mount (mnt) [ edit ] Mount namespaces, the first namespace to be added to Linux, control mount points . They provide a process with an isolated view of the filesystem hierarchy. Upon creation, the mounts from the current mount namespace are initially copied to the new namespace. However, mount points created or unmounted afterwards do not propagate between namespaces by default. Using the Linux shared subtrees feature, it is possible to configure specific mount points to propagate events (such as a USB drive being mounted) between the host and the container, or vice versa. [ 10 ] The clone flag used to create a new namespace of this type is CLONE_NEWNS . Process ID (pid) [ edit ] The PID namespace provides processes with an independent set of process IDs (PIDs). PID namespaces are strictly nested. When a new process is created within a new PID namespace, it will have a distinct PID for each namespace from its current namespace up to the initial (root) PID namespace. Hence, processes in the initial PID namespace (like the host operating system) are able to see all processes across all containers, albeit with different PIDs than those seen inside the containers. The first process created in a PID namespace is assigned process ID number 1. It receives much of the same special treatment as the host system's normal init process. Most notably, any orphaned processes within the namespace are automatically reparented to this PID 1 process. If this PID 1 process terminates, the kernel will immediately terminate all other processes within that PID namespace and any of its descendants by sending them a SIGKILL signal. [ 11 ] Network (net) [ edit ] Network namespaces virtualize the network stack . Upon creation, a new network namespace contains only a loopback interface ( lo ), which is initially down. Each network interface—whether physical or virtual—can only be present in exactly one network namespace at a time, but interfaces can be actively moved between namespaces by an administrator. Each network namespace maintains a private set of IP addresses , its own routing table , socket listing, connection tracking table, firewall rules (such as iptables or nftables ), and other network-related resources. [ 5 ] To grant a container network connectivity, administrators typically create a Virtual Ethernet ( veth ) pair, placing one end in the host namespace and the other inside the container's network namespace, and then bridge the host end to a physical network. Destroying a network namespace automatically destroys any virtual interfaces within it and moves any physical interfaces back to the initial network namespace. Inter-process Communication (ipc) [ edit ] IPC namespaces isolate processes from SysV style inter-process communication mechanisms, as well as POSIX message queues. This prevents processes in different IPC namespaces from interacting with each other using common IPC identifiers. For example, two processes in different namespaces can use the same shared memory segment identifier to allocate memory via the SHM family of functions, and the kernel will guarantee that they are provided with two distinct, fully isolated regions of shared memory. UTS [ edit ] UTS namespaces isolate two system identifiers: the hostname and the NIS domain name . The name "UTS" originates from the data structure passed to the uname system call, which historically stands for UNIX Time-Sharing System. When a process creates a new UTS namespace, the hostname and domain name are copied from the caller's namespace. The processes inside the new namespace can then change their hostname without affecting the host machine or other containers. [ 12 ] User ID (user) [ edit ] User namespaces are a critical security feature designed to provide both privilege isolation and user identification segregation across multiple sets of processes. Introduced completely in kernel 3.8, they are the backbone of unprivileged containers. Like PID namespaces, user namespaces are nested, with each new namespace considered a child of the one that created it. A user namespace maintains a mapping table that converts user IDs (UIDs) and group IDs (GIDs) from the container's internal perspective to the host system's global perspective. This allows a process to possess root privileges (UID 0) inside the container, but mathematically map to an unprivileged, restricted user ID (e.g., UID 100000) on the underlying host machine. [ 13 ] If a vulnerability allows the container's "root" process to break out of the namespace, the host system will still treat it as the restricted user ID, severely limiting the potential damage. Control group (cgroup) Namespace [ edit ] The cgroup namespace hides the identity of the control group hierarchy to which a process belongs. Before this namespace existed, a process inside a container could inspect /proc/self/cgroup and see the entire path of its cgroup relative to the host system (e.g., /sys/fs/cgroup/memory/docker/container_id ). By virtualizing the cgroup filesystem view, a process inside a cgroup namespace will see its own cgroup directory as the root ( / ). This prevents information leaks about the host's underlying infrastructure and allows container orchestration tools to seamlessly migrate containers between nodes without conflicting cgroup paths. This namespace type has existed since March 2016 in Linux 4.6. [ 14 ] Time [ edit ] The time namespace allows processes to observe different system times. It was introduced in Linux 5.6 in March 2020. Specifically, it isolates two specific kernel clocks: CLOCK_MONOTONIC and CLOCK_BOOTTIME . When a container is migrated from one physical host to another or restored from a snapshot, the system uptime and monotonic clock values of the new host will naturally differ from the old one. The time namespace allows the container runtime to set clock offsets, ensuring that applications inside the container do not experience sudden, disruptive jumps in time. Proposed namespaces [ edit ] syslog namespace [ edit ] The syslog namespace was proposed by Rui Xiang, an engineer at Huawei , to isolate kernel logging rings. However, the proposal was not merged into the mainline Linux kernel. [ 15 ] Instead, user-space solutions largely fulfilled this requirement; for instance, systemd introduced the concept of "journal namespaces" in February 2020 to provide isolated log environments. [ 16 ] IMA namespace [ edit ] The Integrity Measurement Architecture (IMA) is a kernel security subsystem that measures files before they are accessed to ensure they have not been tampered with. Standard IMA operates globally, which causes conflicts in containerized environments. Ongoing development by the kernel community—with significant contributions from IBM and Huawei—aims to introduce an IMA namespace. This would allow each container to maintain isolated Platform Configuration Registers (PCR), unique Measurement Logs (ML), and independent appraisal keys, thereby bringing hardware-level cryptographic attestation directly to individual containers. [ 17 ] Administrative hierarchy [ edit ] To facilitate privilege isolation for administrative actions, every namespace type is tied to a user namespace. When a non-user namespace is created, it is considered "owned" by the user namespace that was active at the moment of its creation. A user with administrative privileges (specifically, possessing the CAP_SYS_ADMIN capability ) in the owning user namespace is allowed to perform administrative actions on that namespace. For example, if a process has administrative permissions to change the IP address of a network interface, it may do so, but only if its active user namespace owns that specific network namespace. Because the initial (host) user namespace is the ancestor of all other namespaces, the host's root user inherently retains administrative control over all namespace types across the entire system. [ 18 ] Implementation details [ edit ] Namespaces are represented as virtual file objects within the kernel, accessible via the procfs pseudo-filesystem. Visibility in /proc [ edit ] The kernel exposes the namespace associations of each running process at the path /proc/ pid /ns/ kind . Like many non-file resources in /proc , these entries manifest as special symbolic links. Reading the link yields a string formatted as kind :[ inode_number ] . These inode numbers correspond one-to-one with unique namespace objects in the kernel memory. If two processes show the same inode number for a specific namespace kind (e.g., net:[4026531969] ), they share that namespace. As of Linux 6.1.0, the kind string can be any of cgroup , ipc , mnt , net , pid , time , user , or uts . Additionally, for namespaces where children processes might inherit different traits than the parent itself (such as PID or user namespaces), the kernel provides /proc/ pid /ns/ kind _for_children links. Syscalls [ edit ] Four core system calls directly manipulate namespaces: clone : Used to spawn a new process. By passing specific flags (such as CLONE_NEWPID or CLONE_NEWNET ), the kernel will create the specified new namespaces and place the child process inside them. unshare : Allows a process to disassociate parts of its execution context from its parent, effectively moving the calling process into a brand new namespace. setns : Allows a running process to enter an already existing namespace. It requires a file descriptor pointing to one of the namespace symbolic links in /proc . ioctl : Used with specific namespace requests (like NS_GET_PARENT or NS_GET_USERNS ) to discover the hierarchical relationships between different namespaces. Destruction [ edit ] If a namespace is no longer referenced by any part of the system, the kernel will automatically destroy it. The cleanup process for the contained resources varies depending on the namespace kind. A namespace is considered actively referenced and kept alive as long as any of the following conditions are met: It contains at least one living member process. It has at least one referenced child namespace (for nested types like PID and User). Its virtual file ( /proc/ pid /ns/ kind ) is currently held open via a file descriptor . It underpins a bind mount created in the filesystem (a common technique used by networking tools like iproute2 to keep network namespaces alive without running processes). Adoption [ edit ] Linux namespaces are ubiquitously adopted across the modern software landscape. They are universally combined with cgroups to build container technologies. Examples include Docker , [ 19 ] LXC (Linux Containers), Podman , and container orchestration systems like Kubernetes . Beyond pure containers, namespaces are extensively utilized for process sandboxing and security. Google Chrome and Chromium heavily rely on user, PID, and network namespaces to sandbox web rendering processes, severely limiting the damage an attacker can inflict if a renderer is compromised. [ 20 ] Package formats like Flatpak and Snap employ namespaces to isolate desktop applications from the host filesystem and user data. Furthermore, the init system systemd uses namespaces to secure system services. Directives such as PrivateNetwork=yes or PrivateTmp=yes in a systemd service file instruct the kernel to spawn the daemon inside isolated network and mount namespaces, respectively. Command-line utilities also make use of these features. The util-linux package includes the unshare command, which allows users to start shells or scripts inside newly created namespaces. An example of utilizing namespaces to create an isolated, unprivileged root-like environment: unshare --map-root-user --fork --pid --mount-proc --root = " ${ chrootdir } " " $@ " This command spawns a process in new user, PID, and mount namespaces, effectively acting as a modern, far more secure equivalent to the traditional chroot . References [ edit ] ^ Heddings, Anthony (2020-09-02). "What Are Linux Namespaces and What Are They Used for?" . How-To Geek . Retrieved 2024-08-22 . ^ Kerrisk, Michael. "namespaces(7) - overview of Linux namespaces" . man7.org . Retrieved 2026-05-29 . ^ "The Use of Name Spaces in Plan 9" . 1992. Archived from the original on 2014-09-06 . Retrieved 2016-03-24 . ^ Kerrisk, Michael (2013-01-04). "Namespaces in operation, part 1: namespaces overview" . LWN.net . Archived from the original on 2024-03-21 . Retrieved 2026-05-29 . ^ a b "network_namespaces(7) - Linux manual page" . man7.org . Retrieved 2026-05-29 . ^ "LKML: Linus Torvalds: Linux 3.8" . lkml.org . Retrieved 2024-03-22 . ^ "Namespaces in operation, part 5: User namespaces [LWN.net]" . ^ Heo, Tejun (2016-03-18). "[GIT PULL] cgroup namespace support for v4.6-rc1" . lkml (Mailing list). ^ "It's Finally Time: The Time Namespace Support Has Been Added To The Linux 5.6 Kernel" . Phoronix . Retrieved 2020-03-30 . ^ "Documentation/filesystems/sharedsubtree.txt" . 2016-02-25 . Retrieved 2017-03-06 . ^ "Namespaces in operation, part 3: PID namespaces" . lwn.net. 2013-01-16. ^ "uts_namespaces(7) - Linux manual page" . man7.org . Retrieved 2021-02-16 . ^ "user_namespaces(7) - Linux manual page" . man7.org . Retrieved 2026-05-29 . ^ Torvalds, Linus (2016-03-26). "Linux 4.6-rc1" . lkml (Mailing list). ^ "Add namespace support for syslog" . lwn.net . Retrieved 2022-07-11 . ^ "journal: add concept of "journal namespaces" by poettering · Pull Request #14178 · systemd/systemd" . GitHub . Retrieved 2022-07-11 . ^ "ima: Introduce IMA namespace" . lwn.net . Retrieved 2024-03-18 . ^ "Namespaces in operation, part 5: User namespaces" . lwn.net. 2013-02-27. ^ "Docker security" . docker.com . Retrieved 2016-03-24 . ^ "Chromium Linux Sandboxing" . Archived from the original on 2019-12-19 . Retrieved 2019-12-19 . External links [ edit ] namespaces(7) - Linux manual page Namespaces — The Linux Kernel documentation Linux kernel Namespaces and cgroups by Rami Rosen Namespaces and cgroups, the basis of Linux containers (including cgroups v2) - slides of a talk by Rami Rosen, Netdev 1.1, Seville, Spain (2016) v t e Virtualization software Comparison of platform virtualization software Hardware ( hypervisors ) Native CP/CMS Hyper-V KVM oVirt LDoms / Oracle VM Server for SPARC Logical partition (LPAR) LynxSecure PikeOS Proxmox VE QNX SIMMON SmartOS VMware ESXi VMware vSphere vCloud VMware Infrastructure Xen XenServer XCP-ng z/VM Hosted Specialized Basilisk II Bochs Cooperative Linux DOSBox DOSEMU 86Box PCem PikeOS SheepShaver SIMH Windows on Windows Virtual DOS machine Win4Lin Independent bhyve Microsoft Virtual Server Parallels Workstation Extreme Parallels Desktop for Mac Parallels Server for Mac PearPC QEMU UTM VirtualBox Virtual Iron Virtual PC VMware Fusion VMware Server VMware Workstation Player Tools Ganeti System Center Virtual Machine Manager Virt-manager Operating system OS containers FreeBSD jail Linux-VServer LXC OpenVZ Solaris Containers sysjail Virtuozzo Workload Partitions Application containers Apptainer Distrobox Docker lmctfy Podman rkt Virtual kernel architectures Rump kernel User-mode Linux vkernel Related kernel features BrandZ cgroups chroot namespaces eBPF seccomp Orchestration Amazon ECS Kubernetes OpenShift Desktop Citrix Virtual Apps Citrix Virtual Desktops Omnissa Horizon Remote Desktop Services Virtual machine Application Ceedo Citrix Virtual Apps Dalvik InstallFree Microsoft App-V Remote Desktop Services Symantec Workspace Virtualization Turbo VMware ThinApp ZeroVM Network Distributed Overlay Virtual Ethernet (DOVE) Ethernet VPN (EVPN) NVGRE Open vSwitch Virtual security switch Virtual Extensible LAN (VXLAN) Generic Network Virtualization Encapsulation (GENEVE) See also BlueStacks See also: List of emulators , List of computer system emulators v t e Linux kernel Organization Kernel Linux Foundation Linux Mark Institute Linus's law Tanenbaum–Torvalds debate Tux SCO disputes Linaro GNU GPL v2 menuconfig Supported computer architectures Version history Criticism Support Developers The Linux Programming Interface kernel.org LKML Linux conferences Users Linux User Group (LUG) People Werner Almesberger H. Peter Anvin Jens Axboe Moshe Bar Suparna Bhattacharya Andries Brouwer Rémy Card Alan Cox Matthew Garrett Avi Kivity Con Kolivas Greg Kroah-Hartman Robert Love David S. Miller Ingo Molnár Andrew Morton Hans Reiser Rusty Russell Shuah Khan Linus Torvalds Theodore Ts'o Stephen Tweedie Harald Welte Chris Wright Technical Debugging CRIU ftrace kdump Linux kernel oops SystemTap BPF eBPF Startup vmlinux System.map dracut initrd initramfs ABIs Linux Standard Base x32 ABI APIs Kernel System Call Interface POSIX ioctl select open read close sync … Linux-only futex epoll splice dnotify inotify readahead … In-kernel ALSA Crypto API io_uring DRM kernfs Memory barrier New API RCU Video4Linux IIO Userspace Daemons , File systems bpffs configfs devfs devpts debugfs FUSE hugetlbfs pipefs procfs securityfs sockfs sysfs tmpfs systemd udev Kmscon binfmt_misc Wrapper libraries C standard library glibc uClibc Bionic libhybris dietlibc EGLIBC klibc musl Newlib libcgroup libdrm libalsa libevdev libusb liburing Components Kernel modules BlueZ cgroups Console bcache Device mapper dm-cache dm-crypt DRM EDAC evdev Kernel same-page merging (KSM) LIO Framebuffer LVM KMS driver Netfilter Netlink nftables Network scheduler perf SLUB zram zswap Process and I/O schedulers : Brain Fuck Scheduler Completely Fair Scheduler (CFS) Earliest eligible virtual deadline first (EEVDF) Noop scheduler O(n) scheduler O(1) scheduler SCHED_DEADLINE SCHED_FIFO SCHED_RR Security Modules : AppArmor Exec Shield seccomp SELinux Smack Tomoyo Linux Linux PAM Device drivers 802.11 graphics Raw device initramfs KernelCare kexec kGraft kpatch Ksplice Variants Mainline Linux kernel Linux-libre High-performance computing INK Compute Node Linux SLURM Real-time computing RTLinux RTAI Xenomai PREEMPT_RT MMU -less μClinux PSXLinux Virtualization Hypervisor KVM Xen OS-level virtualization Linux-VServer Lguest LXC OpenVZ Other L4Linux User-mode Linux MkLinux coLinux Adoption Range of use Desktop Embedded Gaming Thin client: LTSP Server: LAMP LYME-LYCE Devices Adopters List of Linux adopters Linux portal Free and open-source software portal Category Retrieved from " https://en.wikipedia.org/w/index.php?title=Linux_namespaces&oldid=1356697396 " Categories : Interfaces of the Linux kernel Linux kernel features Operating system security Virtualization software for Linux Hidden categories: Articles with short description Short description is different from Wikidata This page was last edited on 29 May 2026, at 07:53  (UTC) . Text is available under the Creative Commons Attribution-ShareAlike 4.0 License ; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy . Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc. , a non-profit organization. Privacy policy About Wikipedia Disclaimers Contact Wikipedia Legal & safety contacts Code of Conduct Developers Statistics Cookie statement Mobile view Search Search Toggle the table of contents Linux namespaces 5 languages Add topic