The 7 most used Linux namespaces

I want to provide some examples to clarify the technical definitions around namespaces. Wikipedia has the following definition:

Namespaces are a feature of the Linux kernel that partitions kernel resources such that one set of processes sees one set of resources and another set of processes sees a different set of resources. The feature works by having the same namespace for a group of resources and processes, but those namespaces refer to distinct resources.

This definition is quite a bit to digest for some folks, so perhaps this analogy will help. Consider my apartment building. It's technically two distinct buildings with their own entrances. However, the parking garage, gym, pool, and common rooms are shared. The buildings have their own names, City Place and City Place 2. They have their own street addresses, floors, and elevators. Yet, they are attached to the same physical complex.

The physical complex is the same idea as a computer. Two namespaces (or more) can reside on the same physical computer, and much like the apartment building, namespaces can either share access to certain resources or have exclusive access.

There are seven common types of namespaces in wide use today. Using the apartment as our guide, let's walk through a summary of what each type does. Below is a brief overview of each namespace type. In subsequent articles, we will show how each namespace works by example.

Process isolation (PID namespace)

A PID, or process ID helps a system track a specific task on a computer. When you launch Firefox on your computer, it will have a PID associated with it. In order to make sure that the computer interacts with a task properly, the task is referenced by the PID. Let's assume that you have Firefox and the Brave Browser open at the same time. You fire up your preferred search engine, such as DuckDuckGo, in each browser and search for cat pictures in one and dog pictures in the other. Both browsers are making a similar request to the same website. How does the computer ensure that the correct search results are returned to the correct browser? One of the main ways is by tracing the requests each PID makes and then returning the results to the requesting process.

"Great, I'm lost," you say. What does this have to do with apartment buildings and namespaces? Well, let's say that you want to run identical copies of a piece of software. Some software was not written to have more than one copy open at a time. To accomplish this, you might have to isolate the PID so that it is not aware of what is going on outside of its own processes. This is what process isolation can help to solve.

To put it another way, going back to our apartment building, the individual apartments in the complex are similar to the PID namespace. Each household in the apartment complex wants to turn on their TVs and watch a variety of content. In a silly parallel universe, imagine that when a single person in the apartment building turned on their TV, no one else could watch TV because otherwise, the cable provider wouldn't know which TV should be watching "The Office" and which "The Apprentice." Namespaces would allow the cable company to isolate each household and provide distinct programming to each resident because it no longer matters what other people in your complex are viewing.

[ Learn more about PID namespaces. ]

Network interfaces (net namespace)

Every computer that is connected to a network (such as the internet) requires an IP address. This is a unique number that allows computers to communicate effectively. When a specific type of resource is accessed, say a web page, there is a particular port used for that communication. This is because a computer could host a web server, a game server, and perhaps an email server on the same host. The ports might be 80 or 443 for web traffic, 8888 for game traffic, and 25 for email. When I type https://<website address> into my browser, the computer translates it to send the traffic to the browser's IP xxx.xxx.xxx.xxx on port 443. The server on the other end then replies with the appropriate content via the source IP address. Some technology stacks, as mentioned before, do not support multiple instances of the software running concurrently. Unlike PID isolation, however, when software such as an email server is receiving a connection, it expects to be on a specific port. So even if you isolated the PID, the email server would only have a single instance running because port 25 is already in use. Network namespaces allow processes inside each namespace instance to have access to a new IP address along with the full range of ports. Thus, you could run multiple versions of an email server listening on port 25 without any software conflicts.

In my building scenario, the buildings are attached to the same physical complex and are mirror images of each other. This means there are the same amount of living spaces in each building. In addition, they follow the same apartment numbering schema. This means that each building has Unit 707, for example. In this example, the IP address is like the street address of the apartment buildings, and the apartment number is the port. Each apartment complex is part of the same physical building, but they have different street addresses. Since the buildings are not physically separate, without this net namespace a company sending a bill to Steve Ovens, 123 Fake Street Unit 707 might not ever receive a reply because it went to the wrong address. More likely, the post office simply would not attempt to deliver the letter due to the ambiguity of the address. However, net namespaces allow us to have 123 Fake Street and 125 Fake Street in the same physical building.

[ Learn more about net namespaces. ]

Unix Timesharing System (uts namespace)

This namespace is unfortunately named by today's standards. It dates back to the early days of Unix and has to do with how information was stored for a specific system call. Today, this detail is largely lost to history and what you really need to know is that the UTS namespace allows for the segregation of hostnames. Often hostnames are simply a convenience. As mentioned earlier, with some exceptions, most communication to and from a host is done via the IP address and port number. However, it makes life a lot easier for us humans when we have some sort of name attached to a process. Searching through log files, for instance, is much easier when identifying a hostname. Not the least of which because, in a dynamic environment, IPs can change.

In our building analogy, the hostname is similar to the name of the apartment building. Telling the taxi driver I live in City Place apartments is usually more effective than providing the actual address. Having multiple hostnames on a single physical host is a great help in large containerized environments.

[ Learn more about uts namespaces. ]

User namespace

Every computer system has some way of tracking which user owns which file(s). This allows the system to restrict access to sensitive system files. It also prevents people using the same computer from accessing each others' files. To the end-user, the files are shown to be owned by a login name such as stratus. To the computer, however, this is just an arbitrary combination of alphanumeric characters. In order to track these permissions correctly, there is a process of mapping the user stratus to a specific user identification (UID) number, such as 1001. This UID is then applied to the metadata of the file. This allows you to change your username to stratus1 without the system having to do a significant amount of metadata updating. The mapping file gets updated so that UID 1001 is then associated with stratus1 instead of stratus. The entry is changed in a single (or a small number) of places.

Think of this as similar to the mailboxes on the floor of my apartment building. Each mailbox has a name or multiple names associated with it. When someone wishes to deliver mail to me, they put the mail in box 707, for example. Should I decide to change my name, or add my wife's name to the mailbox, nothing changes. The mail still goes to the same location, only the authorized persons can view these files, and my key to unlock the box stays unchanged.

[ Learn more about user namespaces. ]

Mount (mnt namespace)

The mount namespace is used to isolate mount points such that processes in different namespaces cannot view each others' files. If you are familiar with the chroot command, it functions similarly.

In our analogy, I am going to deviate a little from the apartment. Let's assume two people get married. In this scenario, there are a bunch of things that usually end up being shared. You probably put their name on the address listing, you might have both names on the bills, have both names on any car ownerships, and add them to your credit cards, etc. In this sense, you are sharing the same mount point with the other person. However, their credit may be separate, they might pay their own taxes, and so on. Their Social Insurance number (Social Security number for our friends in the USA) stays distinct from yours and vice versa. Therefore, while your partner may see a similar view of the financial situation, it will not be exactly the same. They have no real ability to see any financial matters that are legally your sole possession.

The same is true for filesystem mount points. By default, different mount namespaces cannot view the other's content. As far as the namespace is concerned, it is at the root of the file system, and nothing else exists. However, you can mount portions of an underlying file system into the mount namespace, thereby allowing it to see additional information.

[ Learn more about mnt namespaces. ]

Interprocess communication (IPC)

This namespace is highly technical and complex to understand and describe. So much so that Marty Kalin has a series of articles on Opensource.com detailing interprocess communication (IPC). If you are really interested, I will refer you to Marty's series as I could not do this topic justice. IPCs handle the communication between processes by using shared memory areas, message queues, and semaphores. If all of that sounds foreign to you, don't worry, you aren't alone. The most common application for this type of management is possibly the use of databases.

If we zoom in on a single aspect of IPC, shared memory, we can get a basic understanding of the importance. In programming, whenever the application needs to keep track of some information temporarily, it requests that the operating system dedicate a certain amount of random access memory (RAM) to its process. You can think of this, similar to starting a conversation with someone in a chat program. By default, there are only two recipients, yourself and the person on the other end, or thought of another way, the operating system, and the application. Both participants can see the entire history of the conversation, but no one else can. However, if someone new is invited into the chat, they too can read and participate in the discussion. Shared memory can act similarly, allowing two or more programs to have access to the same information. A change by one program will be immediately visible to the other program.

Cgroups

For an in-depth look at cgroups, I recommend reading my series on redhat.com. In that four-part series, I go into detail about how cgroups work and how you can put them into practice. In brief, cgroups are a mechanism for controlling system resources. When a cgroup is active, it can control the amount of CPU, RAM, block I/O, and some other facets which a process may consume. By default, cgroups are created in the virtual filesystem /sys/fs/cgroup. Creating a different cgroup namespace essentially moves the root directory of the cgroup. If the cgroup was, for example, /sys/fs/cgroup/mycgroup, a new namespace cgroup could use this as a root directory. The host might see /sys/fs/cgroup/mycgroup/{group1,group2,group3} but creating a new cgroup namespace would mean that the new namespace would only see {group1,group2,group3}.

You might wonder why this might be needed. Part of this is security related. If a new cgroup namespace was not created, there is a potential to leak information. The man page says it best:

It prevents information leaks whereby cgroup directory paths outside of a container would otherwise be visible to processes in the container. Such leakages could, for example, reveal information about the container framework to containerized applications.

In a traditional cgroup hierarchy, there is a possibility that a nested cgroup could gain access to its ancestor. This means that a process in /sys/fs/cgroup/mycgroup/group1 has the potential to read and/or manipulate anything nested under mycgroup.

Finally, thinking specifically of containers, cgroup namespaces allows containers to be agnostic of ancestor cgroups. This is important to something like OpenShift, which may migrate containers between hosts. Without the isolation provided by namespaces, the full cgroup path names would need to be replicated on a new host when migrating a container. Since pathing must be unique, cgroup namespaces help avoid conflicts on the new host system.

In terms of the building analogy, a cgroup is similar to the utilities in each unit. While cgroups can limit resource usage, it also can act as an accountant. So while my apartment doesn't prevent me from using a certain amount of power or water, it definitely tracks (and bills) my usage. That usage is just a tiny part of the usage of the building as a whole. I do not know the building's total usage (my apartment's ancestor), nor can I know how much my neighbor is utilizing. They are in a completely different cgroup namespace.

[ Get this free ebook: Managing your Kubernetes clusters for dummies. ]

Wrapping up

So there you have a brief overview of what the seven most used namespaces are. Hopefully, my analogy was useful and clear. In the next couple of articles, I explore some of these namespaces and how they are created by hand. This will give you a better understanding of the utility of namespaces. In the final article, I tie it all together, including the use of cgroups to explain how containers function "under the hood."