# Linux Namespaces: Die unsichtbaren Wände des Systems

TL;DR / Management Summary Während Cgroups (Artikel 374) die Ressourcen begrenzen, isolieren Namespaces die Sicht auf das System. Ein Prozess in einem Namespace glaubt, er sei allein auf dem Server: Er sieht nur seine eigenen Prozess-IDs (PID), seine eigenen Netzwerk-Interfaces und sein eigenes Root-Dateisystem. Namespaces sind das Fundament von Docker, Podman und LXC. Wer sie beherrscht, kann Prozesse so tief einsperren, dass sie den restlichen Host nicht einmal “sehen” können.

# 1. Einführung & Architektur

Die Trennung der Realitäten.

Ein Namespace ist eine Kernel-Abstraktion, die es erlaubt, globale Systemressourcen in logische Einheiten zu unterteilen.

# Die 7 Säulen der Isolation (Mermaid)

graph TD
    A[Linux Kernel] --> B[mnt: Mount Points]
    A --> C[pid: Process IDs]
    A --> D[net: Network Stack]
    A --> E[uts: Hostname / Domain]
    A --> F[ipc: Message Queues]
    A --> G[user: UID / GID Mapping]
    A --> H[cgroup: Hierarchy View]
    subgraph "Container Reality"
        B --- I[Isolated Instance]
        C --- I
        D --- I
    end

# 2. Die wichtigsten Namespaces im Detail

Wo wird isoliert?

# 1. Mount (mnt)

Isoliert die Liste der Mount-Punkte. Ein Prozess kann Dateien mounten/unmounten, ohne dass der Host es sieht. Basis für chroot.

# 2. Network (net)

Der Prozess bekommt eine eigene Loopback-Schnittstelle, eigene IPs und Routing-Tabellen.

# Erstellt einen neuen Netzwerk-Namespace
ip netns add test-ns

# 3. User (user)

Erlaubt es, dass ein Prozess im Container root (UID 0) ist, auf dem Host aber als normaler User (UID 1000) läuft. (Basis für Rootless-Container).

# 3. Manuelle Interaktion

In den Namespace eintauchen.

Nutzen Sie die Werkzeuge unshare (erstellt neuen Namespace) und nsenter (wechselt in bestehenden).

# Beispiel: Eine isolierte Shell starten

# Startet Bash mit eigenem Hostnamen und neuem Mount-Layout
sudo unshare --uts --mount /bin/bash
hostname my-sandbox

Ändern Sie den Hostnamen in dieser Shell – er wird sich auf dem Hauptsystem nicht ändern!

# In einen Docker-Container “einbrechen” (via Kernel)

Anstatt docker exec können Sie direkt via Namespace zugreifen:

# Finde die PID des Containers
PID=$(docker inspect -f '{{.State.Pid}}' web01)
# Betrete den Netzwerk-Namespace des Containers
sudo nsenter -t $PID -n ip addr

# 4. Day-2 Operations: Inspektion

Wer gehört zu wem?

# Namespaces auflisten

lsns
# Zeigt alle Namespaces im System und die zugehörigen PIDs.

# Namespace-Links im Dateisystem

Jede PID hat ihre Namespaces unter /proc/ verlinkt:

ls -l /proc/self/ns/

# 5. Troubleshooting & “War Stories”

Wenn die Isolation zum Gefängnis wird.

# Story 1: “Der unsichtbare Dienst”

Symptom: Ein Admin startet einen Datenbank-Server in einem Namespace. Der Dienst läuft (ps sieht ihn), aber er ist über das Netzwerk nicht erreichbar, obwohl die Firewall offen ist. Ursache: Der Dienst läuft in einem eigenen Network-Namespace und hat keine Verbindung (veth-pair) zum Hauptnetzwerk des Hosts. Lösung: Nutzen Sie ip link add veth0 type veth peer name veth1 und verschieben Sie ein Ende in den Namespace des Dienstes.

# Story 2: “Das hängende Mount-Device”

Symptom: Ein externes USB-Laufwerk lässt sich auf dem Host nicht unmounten (Device busy), obwohl kein Prozess darauf zugreift. Ursache: Ein Backup-Container wurde gestartet, während das Laufwerk gemountet war. Der Container hat den Mount-Namespace geerbt und hält das Device nun intern offen. Lösung: Finden Sie den Container mit lsns -t mnt und beenden Sie ihn, oder nutzen Sie umount -l (Lazy Unmount).

# 6. Fazit & Empfehlung

• Sicherheit: Namespaces sind die wichtigste Härtungsebene für Multi-Tenant-Systeme.
• Wahl: Nutzen Sie Rootless Podman, um die Vorteile von user-Namespaces voll auszuschöpfen.
• Wartung: Nutzen Sie lsns, um verwaiste Namespaces von abgestürzten Applikationen zu finden.

# Anhang: Cheatsheet