0 Lightweight Namespace Shell unshare --user --map-root-user --mount --pid --fork bash.md

Lightweight Namespace Shell: unshare --user --map-root-user --mount --pid --fork bash

unshare --user --map-root-user --mount --pid --fork bash is a compact one-liner that starts a new interactive shell with several Linux namespaces isolated. It’s a handy way to get a “root” shell that’s isolated from the rest of the system — useful for experimenting, testing, and lightweight container-like isolation without full container tooling.

The command

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

What each piece does (plain English)

• unshare: the program that asks the kernel to run the following process in new namespace(s).
• --user: creates a new user namespace. Inside that namespace you can have different UID/GID mappings than on the host.
• --map-root-user: map your current unprivileged user to UID 0 (root) inside the new user namespace. In other words, inside the namespace you appear as root, but outside you remain an ordinary user.
• --mount: create a new mount namespace, so mounts and unmounts you do inside the shell don’t affect the host’s mount table.
• --pid: create a new PID namespace. Process numbering is independent inside this namespace; the shell will appear as PID 1 there and can see only descendant processes.
• --fork: fork a new process for the namespace boundary (commonly used when creating PID namespaces so the new namespace has its own PID 1).
• bash: the program to run inside the new namespaces — here, an interactive Bash shell.

What you get inside the shell

• Running id will typically show uid=0(root), because of the user mapping. However, this “root” is confined to the namespace and does not equal host root privileges in the usual global sense.
• You can mount and unmount filesystems inside the mount namespace (if the kernel permits unprivileged mounts), and those changes will be invisible to other processes on the host.
• Processes you launch are PID-isolated — a ps inside shows only processes in the namespace, and the shell acts like PID 1 for that namespace.

Typical uses

• Quick experiments that require root inside an isolated environment (e.g., testing init behavior, experimenting with mounts).
• Lightweight, throwaway “containers” for development/testing without Docker/Podman.
• Learning and demonstrating Linux namespaces, PID 1 behavior, and how UID mapping works.

Important cautions and limitations

• Kernel & distro dependent: user namespaces and unprivileged mounts depend on kernel configuration and distribution policies. Some systems disable or restrict user namespaces for unprivileged users.
• Not a full security sandbox: this is namespace isolation, not a complete security boundary. Kernel-level vulnerabilities, certain capabilities, or misconfigured mounts can allow escapes. Treat it as a convenience for testing — not a hardened production sandbox.
• Mount permissions: even if you appear as root inside the user namespace, some mount operations can still be blocked by the kernel or require additional mapping (depending on kernel config and /etc/subuid//etc/subgid setup on some distros).
• Transient: when you exit the bash started by unshare, the namespaces are destroyed. Nothing persists unless you explicitly export or save state.

Quick sanity checks to run inside

• id — confirms the UID mapping.
• ps -ef — shows PID view inside the new PID namespace.
• mount | head or cat /proc/self/mounts — see mounts visible inside the namespace.
• Try creating a mount (if allowed): mount --bind /some/dir /tmp/scratch — then exit and verify the host’s mount table is unchanged.

Summary

This unshare invocation is an excellent, low-friction way to get an isolated shell that feels like a root environment but stays tied to your unprivileged user outside. It’s ideal for learning and quick experiments — just be mindful of kernel/configuration limits and that namespace isolation is not a substitute for full container or VM security.