Ajinkya Singh

Posted on Oct 8

Mount Namespaces and nsenter: Deep Dive

#docker #containers #linux #programming

🚀 I'm Building My Own Container Runtime!

This is part of a complete series where I'm building Conti - a container runtime from scratch. Check it out on GitHub!

About This Series:

I'm sharing everything I learn while building my own container runtime

Most concepts come from videos, documentation, and LLM-assisted learning (for educational purposes)

Focus: Understanding through practice - raw Linux commands and practical implementation

Important: When building your own container, DON'T copy code from sources - it kills the fun! Write it yourself, break things, debug, and learn.

Why Build Your Own?

Deep understanding of how containers really work

Master low-level Linux concepts

Learn by doing, not just reading

It's incredibly fun when things finally click!

Understanding Mount Namespaces

We've already covered what namespaces are. Now let's dive deep into mount namespaces - one of the most critical components for container filesystem isolation.

Mount namespaces control which files and directories are visible to processes. They allow each containerized application to have its own view of the filesystem, preventing interference between applications.

The Isolation Problem

Without mount namespaces, all applications share the same filesystem view:

WITHOUT ISOLATION
─────────────────
📁 /
├── 📁 bin/
├── 📁 etc/
├── 📁 var/
└── 📁 sensitive-data/
    ├── webapp-secrets/      ← App A can see this
    ├── database-config/     ← App B can see this
    └── api-keys/            ← Everyone can see this

⚠️ Security Risk: All apps see all files

With Mount Namespace Isolation

┌──────────────────────┐     ┌──────────────────────┐
│  WebApp Namespace    │     │  Database Namespace  │
│                      │     │                      │
│  📁 /                │     │  📁 /                │
│  ├── bin/            │     │  ├── bin/            │
│  ├── lib/            │     │  ├── lib/            │
│  └── data/           │     │  └── data/           │
│      └── webapp/     │     │      └── db/         │
│                      │     │                      │
│  ✅ Isolated view    │     │  ✅ Isolated view    │
└──────────────────────┘     └──────────────────────┘

Understanding Mount Points

Before we go further, let's understand what "mounting" means.

What is Mounting?

Mounting is the process of making a filesystem accessible at a specific point in the directory tree. Think of your Linux system as a tree that can have different "branches" (filesystems) plugged in at various points.

Storage Device to Unified View

STORAGE DEVICE
──────────────
┌────────┐ ┌────────┐ ┌────────┐
│ Part 1 │ │ Part 2 │ │ Part 3 │
│ (sda1) │ │ (sda2) │ │ (sda3) │
│  ext4  │ │  swap  │ │ btrfs  │
└────────┘ └────────┘ └────────┘
    ↓          ↓          ↓
  [root]    [swap]     [home]

         Kernel Magic ✨
              ↓

UNIFIED FILE SYSTEM
──────────────────
📁 / (from sda1)
├── 📁 bin/
├── 📁 etc/
├── 📁 home/ (mounted from sda3)
├── 📁 var/
└── 📁 usr/

The kernel stitches together multiple physical storage devices into one seamless directory tree.

Types of Mounts

1. Device Mount

Mounting a physical device or partition:

# Mount a USB drive
mount /dev/sdb1 /mnt/usb

# Mount a disk partition
mount /dev/sda3 /home

2. Bind Mount

Mounting an existing directory to another location - making the same content appear in two places:

# Make /source/project appear at /workspace/active
mount --bind /source/project /workspace/active

Bind Mount Visual:

BEFORE BIND MOUNT:
──────────────────
/project/           /workspace/
├── src/            ├── temp/
├── docs/           └── logs/
└── README

AFTER: mount --bind /project /workspace/active
────────────────────────────────────────────
/project/           /workspace/
├── src/            ├── temp/
├── docs/           ├── logs/
└── README          └── active/  ← Now shows
                        ├── src/     project
                        ├── docs/    content
                        └── README

Creating Mount Namespaces

Basic Mount Namespace

# Create new mount namespace
sudo unshare --mount /bin/bash

# Now you're in an isolated mount namespace
# Any mounts you create are invisible outside
mkdir /tmp/isolated
mount --bind /home/user/data /tmp/isolated

# Exit the namespace
exit

# Check from parent - /tmp/isolated won't show the mount
ls /tmp/isolated  # Empty or doesn't exist

Why This Matters for Containers

When a container starts, it needs its own filesystem view:

Container shouldn't see host mounts
Host shouldn't be affected by container mounts
Each container has its own /tmp, /var, etc.

Managing Namespaces with nsenter

Now that we understand mount namespaces, how do we interact with processes running inside them? Enter nsenter.

What is nsenter?

nsenter (namespace enter) allows you to enter the namespaces of an existing process. It's essential for debugging containers and understanding what's happening inside isolated environments.

Command Structure

nsenter --target <PID> [OPTIONS] <command>

# Common options:
--pid      # Enter PID namespace
--mount    # Enter mount namespace
--uts      # Enter UTS namespace
--net      # Enter network namespace
--all      # Enter all namespaces

Practical nsenter Examples

Example 1: Viewing Container Processes

# Find the container's main process
ps aux | grep myapp
# Output: 4500 root /usr/bin/myapp

# Enter its PID namespace and list processes
sudo nsenter --target 4500 --pid ps aux

# You'll see only processes inside that namespace
# PID 1 will be the container's init process

Example 2: Inspecting Container Filesystem

# Enter mount namespace to see what's mounted
sudo nsenter --target 4500 --mount df -h

# Or get a shell inside
sudo nsenter --target 4500 --mount /bin/bash
ls /  # You see the container's root filesystem

Example 3: Full Container Debug Session

# Enter ALL namespaces of process 4500
sudo nsenter --target 4500 --all /bin/bash

# Now you're fully inside the container
hostname        # Container's hostname
ps aux          # Container's processes
ip addr         # Container's network interfaces
mount           # Container's mounts
cat /etc/hosts  # Container's host file

# Exit to return to host
exit

Example 4: Resource Monitoring

# Monitor CPU/memory from inside container
sudo nsenter --target 4500 --pid top

# Check disk usage
sudo nsenter --target 4500 --mount du -sh /var/log

# Network connections
sudo nsenter --target 4500 --net netstat -tuln

Complete Isolation Example

Let's create a container-like environment using multiple namespaces:

# Create PID, Mount, and UTS namespaces
sudo unshare --pid --mount --uts --fork /bin/bash

# At this point you're in isolated namespaces

# Set custom hostname (UTS namespace in action)
hostname my-container
hostname  # Shows: my-container

# Create isolated mount point
mkdir -p /tmp/container-root/{bin,lib,usr,var,tmp}

# Bind mount necessary directories
mount --bind /bin /tmp/container-root/bin
mount --bind /lib /tmp/container-root/lib

# Change root to our isolated filesystem
chroot /tmp/container-root

# Now you have:
# ✅ Isolated PID namespace
# ✅ Isolated mount namespace  
# ✅ Custom hostname
# ✅ Restricted filesystem view

Entering This Container from Outside

# In another terminal, find the container process
ps aux | grep "my-container"
# Let's say PID is 6000

# Enter all its namespaces
sudo nsenter --target 6000 --all /bin/bash

# You're now inside the container
# Same view as if you were inside originally

Key Concepts Recap

Mount Points

Mount Point: Directory where a filesystem is attached
Bind Mount: Making existing directory appear elsewhere
Root Filesystem: Primary filesystem containing system files