I rebuilt my Linux workflow around Namespaces and never looked back

A little while ago, my Linux machine was running excruciatingly slow. I attempted a few fixes: data management, optimization, adjusting Timeshift backups. That sort of thing. During that adventure, I found a few processes that were still causing performance issues. So I turned to Linux Namespaces to improve the visibility of my system processes and run applications safely.

I've used namespaces before, and I just didn't know it

They're a big part of Linux

Credit: David J. Buck / How-To Geek

On the surface, Namespaces remind me of games like Civilization or SimCity. It's all about resource management. The most useful definition I've seen regarding namespaces is “specific processes see one set of specific resources while another set sees a different set of resources.”

There are many namespaces out there, but there are a few that are more common than others, like PID, Mount, and User. Namespaces can get very technical, and I'm still learning about them, but I think it's worth understanding them regardless of whether I use them often or not.

It turns out Docker, LXC, Openstack and plenty of other applications use Namespaces quite a bit on Linux. If you want to see a list of existing Namespaces on your machine, there's a command for that. When I run the command lsns, it brings up a list of the namespaces my system is currently using.

There are several commonly used namespaces

And I'm probably only going to use a few of them

Credit: David J. Buck / How-To Geek

There are many commonly used namespaces on Linux.

There's the PID (Process ID) that tracks a specific task that's running on the computer. In basic terms, they make sure a program can perform specific tasks correctly. PIDs are tracked in the procfs file system. If you're building an isolated environment, as I am, using the PID namespace gives you the ability to use the same PID number across different namespaces.

User namespaces track which users own which files (to be more precise, they map UID/GID values between a namespace and its host machine). Mount namespaces isolate mount points, while Net Namespaces (network interfaces) allow every process inside a namespace to have access to a new IP address and a range of ports. There are also Unix Timesharing System namespaces and IPC (interprocess communication) namespaces

Cgroups aren't namespaces ( they track usage and create limits when necessary) but they do complement them.

Namespaces feel as if they were built for sandboxing

Improving safety and workflow on Linux

Docker, Flatpak, and Podman already provide sandboxed environments, but you can always go a step further by using namespaces for sandboxing.

Namespaces are all about process isolation and visibility. They're not going to change resource usage or improve system performance (you need to combine them with Cgroups for that). Because I like that level of control and visibility, I started using them for sandboxing on Linux a while ago and never looked back.

There are many reasons to sandbox apps. It can be as simple as being an extra security precaution, but the main reason I do it is to keep my PC safe if something goes wrong with the app (or if it becomes compromised). I use namespaces most often to sandbox when I'm testing new installation scripts, running older software, experimenting with configuration, or if I'm doing some system cleanup.

I use the user, mount, and PID namespaces for something like this. Just like I do with Docker, I set my user namespace, so the unprivileged user gets root access, but only in the sandbox itself. Using the mount namespace isolates file system mount points that different processes can see (it does something similar to chroot).

Finally, PID sets it up, so the sandbox processes are isolated and nothing inside the sandbox can see (or even send) host processes on the system.

Using the unshare command, I set up my sandbox:

unshare --user --map-root-user --mount --pid --fork /bin/bash

In extreme layman's terms, unshare invokes the utility, user sets up the username space, map tells the system to act as a root, mount sets up a new mount namespace. PID sets up a new PID name space, while fork creates a "child process" (a process created by another process, basically) of unshare. The /bin/bash makes it an executable shell.

Credit: David J. Buck / How-To Geek

From there, I ran a few apps and an old DOS game called Lemmings in sandboxed mode to test it out. That way, if something goes horribly wrong, my system stays safe. I like that. You could also use chroot or firejail for sandboxing, but I tend to prefer namespaces.

Credit: David J. Buck / How-To Geek

I've considered running multiple browsers and using network namespaces because each browser process will get its own network stack, but as I'm still experimenting with incorporating namespaces into my workflow, I have yet to run a full test.

Namespaces are worth further exploration

Namespaces are complex, but they are well worth exploring for development, testing, or programming on Linux. They've improved my productivity and workflow by just keeping things safer and allowing me to sandbox easily. I'll continue to use them, and I definitely have plans to explore a few of the other namespaces for future projects.