Self-Hosted Rootless Container Infrastructure: RootlessKit vs fuse-overlayfs vs slirp4netns

Running containers as the root user has long been a security concern in self-hosted infrastructure. When a container process runs as root on the host, a container escape vulnerability can grant full system-level access. Rootless container technology eliminates this risk by allowing containers to run entirely under an unprivileged user account, without requiring root privileges or setuid binaries.

Three core technologies enable rootless containers on Linux: RootlessKit for user and mount namespaces, fuse-overlayfs for unprivileged filesystem overlays, and slirp4netns for unprivileged networking. While they serve different purposes, all three are essential building blocks for rootless container runtimes like Podman, Docker Rootless, and nerdctl.

In this guide, we examine each technology, explain how they work together, and provide deployment configurations for self-hosted rootless container infrastructure.

The Rootless Container Problem

Traditional container runtimes (Docker, containerd) require root privileges because they need to:

1. Create user namespaces — mapping container UIDs to host UIDs requires CAP_SYS_ADMIN
2. Mount overlay filesystems — the Linux overlayfs driver historically required root
3. Configure networking — creating virtual Ethernet pairs and bridge interfaces requires root
4. Set cgroup limits — resource accounting and limits are managed by the root-owned cgroup hierarchy

Each of these requirements represents a potential attack surface. If an attacker exploits a container escape vulnerability, they gain root access to the host.

Rootless container technology solves these problems by leveraging three unprivileged alternatives, each addressing one of the core requirements.

Comparison Table

RootlessKit

RootlessKit is the foundational namespace setup tool for rootless containers. It creates the user namespace, mount namespace, and network namespace that allow an unprivileged user to run containers. Think of it as the “entry point” that establishes the sandbox environment.

How It Works

RootlessKit performs three key operations:

1. User namespace creation: Uses unshare(CLONE_NEWUSER) to create a new user namespace where the current user becomes UID 0 (root) inside the namespace, while remaining an unprivileged user on the host.
2. Mount namespace setup: Creates a new mount namespace with a private root filesystem, allowing the container runtime to mount filesystems without affecting the host.
3. Port forwarding: Sets up a built-in port forwarder that maps host ports to container ports without requiring iptables rules or root-level network configuration.

Docker Compose Deployment (RootlessKit + containerd)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

version: "3.8"

services:
  rootless-containerd:
    image: ghcr.io/rootless-containers/rootlesskit:latest
    restart: always
    security_opt:
      - seccomp=unconfined
      - apparmor=unconfined
    environment:
      - ROOTLESSKIT_STATE_DIR=/run/user/1000/rootlesskit
      - HOME=/home/user
    volumes:
      - /home/user/.local/share:/home/user/.local/share
      - /run/user/1000:/run/user/1000
    command: >
      rootlesskit
      --net=slirp4netns
      --copy-up=/etc
      --copy-up=/run
      --port-driver=builtin
      --state-dir=/run/user/1000/rootlesskit
      containerd --config /home/user/.config/containerd/config.toml

Manual Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Install RootlessKit
curl -L https://github.com/rootless-containers/rootlesskit/releases/latest/download/rootlesskit-$(uname -m).tar.gz | tar xz
sudo mv rootlesskit /usr/local/bin/

# Start a rootless shell
rootlesskit --net=slirp4netns --copy-up=/etc bash

# Inside the rootless shell, UID 0 maps to your unprivileged user
id  # uid=0(root) gid=0(root) groups=0(root)

# Launch containerd from within the rootless shell
containerd --config ~/.config/containerd/config.toml

RootlessKit’s --port-driver=builtin option provides efficient port forwarding without requiring a separate port forwarding daemon. The --copy-up flag ensures that modifications to specified directories within the namespace don’t affect the host filesystem.

fuse-overlayfs

fuse-overlayfs implements the Linux overlay filesystem in userspace using FUSE (Filesystem in Userspace). This allows unprivileged users to create overlay filesystems — the core mechanism that container runtimes use to provide each container with its own writable layer on top of a read-only image.

How It Works

Overlay filesystems combine multiple directories into a single unified view:

• Lower layers: Read-only directories from the container image (shared across containers)
• Upper layer: Writable directory unique to each container
• Work directory: Temporary workspace for atomic operations

The native Linux overlayfs kernel module requires root privileges. fuse-overlayfs replicates this functionality in userspace using FUSE, which has been available to unprivileged users since Linux 4.18.

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

version: "3.8"

services:
  fuse-overlayfs-setup:
    image: quay.io/fuse-overlayfs/fuse-overlayfs:latest
    restart: "no"
    privileged: true
    volumes:
      - /dev/fuse:/dev/fuse
      - /etc/subuid:/etc/subuid:ro
      - /etc/subgid:/etc/subgid:ro
    command: >
      sh -c "
        apt-get update && apt-get install -y fuse-overlayfs &&
        echo 'FUSE overlayfs support configured' &&
        # Verify fuse-overlayfs works
        fuse-overlayfs --version
      "

Configuration for Podman

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Install fuse-overlayfs
sudo apt-get install -y fuse-overlayfs

# Configure /etc/containers/storage.conf
cat > /etc/containers/storage.conf << 'EOF'
[storage]
driver = "overlay"

[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
EOF

# Configure subordinate UIDs/GIDs for the user
sudo usermod --add-subuids 100000-165535 $USER
sudo usermod --add-subgids 100000-165535 $USER

# Verify the setup
podman info | grep -A2 graphDriverName
# Should show: graphDriverName: overlay

Performance Considerations

fuse-overlayfs introduces approximately 10-15% I/O overhead compared to native overlayfs due to the FUSE userspace/kernel boundary crossing. For most workloads (web servers, application servers, databases with moderate I/O), this overhead is negligible. For high-I/O workloads (databases with heavy write patterns, log processing), consider:

• Using native overlayfs with rootful containerd if security allows
• Mounting high-I/O directories as tmpfs or bind mounts to bypass the FUSE layer
• Enabling metacopy=on in the overlay options to reduce metadata operations

slirp4netns

slirp4netns provides unprivileged networking for rootless containers by implementing a userspace TCP/IP stack. It creates a virtual network interface inside the user namespace and routes traffic through a userspace NAT, without requiring any root-level network configuration.

How It Works

slirp4netns operates by:

1. Creating a TAP device inside the user namespace — a virtual network interface that appears as a real Ethernet device to processes in the namespace.
2. Running a userspace TCP/IP stack that handles packet routing, NAT, and DNS resolution without kernel-level networking privileges.
3. Forwarding traffic between the TAP device and the host’s network through standard file I/O, which doesn’t require root.

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

version: "3.8"

services:
  slirp-network:
    image: ghcr.io/rootless-containers/slirp4netns:latest
    restart: "no"
    security_opt:
      - seccomp=unconfined
    volumes:
      - /run/user/1000:/run/user/1000
    command: >
      slirp4netns
      --configure
      --mtu=65520
      --enable-sandbox
      --enable-seccomp
      1 tap0

Manual Setup with RootlessKit

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Install slirp4netns
curl -L https://github.com/rootless-containers/slirp4netns/releases/latest/download/slirp4netns-$(uname -m) -o /usr/local/bin/slirp4netns
chmod +x /usr/local/bin/slirp4netns

# Start a rootless container with slirp4netns networking
rootlesskit --net=slirp4netns --slirp4netns-sandbox --slirp4netns-seccomp bash

# Verify networking inside the rootless namespace
ip addr show  # Should show tap0 interface
ping -c 1 8.8.8.8  # Should work

# Map host ports to the container
rootlesskit --net=slirp4netns   --publish 8080:80   --publish 4443:443   containerd-shim-runc-v2

Advanced Configuration

1
2

# slirp4netns with custom DNS and MTU
slirp4netns   --configure   --mtu=65520   --enable-sandbox   --enable-seccomp   --disable-host-loopback   --cidr=10.0.2.0/24   --dns=10.0.2.3   1 tap0

The --enable-sandbox and --enable-seccomp flags activate additional security measures that restrict the userspace networking stack from accessing files and making system calls beyond what’s necessary for packet forwarding.

How the Three Work Together

In a complete rootless container runtime, these three technologies form a stack:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

┌─────────────────────────────────────────────┐
│           Container Process                  │
├─────────────────────────────────────────────┤
│        RootlessKit (namespaces)              │
│  ├── User namespace (UID mapping)            │
│  ├── Mount namespace (private mounts)        │
│  └── Network namespace (isolated net)        │
├─────────────────────────────────────────────┤
│     fuse-overlayfs (filesystem)              │
│  ├── Lower layers (image, read-only)         │
│  ├── Upper layer (container, writable)       │
│  └── Work directory (atomic ops)             │
├─────────────────────────────────────────────┤
│       slirp4netns (networking)               │
│  ├── TAP device (virtual NIC)                │
│  ├── Userspace TCP/IP stack                  │
│  └── NAT/DNS forwarding                      │
└─────────────────────────────────────────────┘

When you run podman run or dockerd-rootless.sh as an unprivileged user:

1. RootlessKit sets up the namespace sandbox
2. fuse-overlayfs provides the container’s filesystem layers
3. slirp4netns provides network connectivity
4. The container runtime (runc, crun, or youki) starts the process inside this environment

Why Rootless Containers Matter for Self-Hosting

Security isolation is the primary motivation. When containers run as root, a single vulnerability in any containerized application can compromise the entire host. Rootless containers confine potential damage to the unprivileged user’s permissions — no access to host system files, no ability to modify kernel parameters, no access to other users’ data.

Multi-tenant self-hosting becomes practical with rootless containers. When different users or services run in their own rootless namespaces, they cannot affect each other’s containers or filesystems. This is essential for shared hosting environments, developer workstations, and CI/CD platforms where multiple untrusted workloads run on the same machine.

Compliance requirements increasingly mandate non-root container execution. SOC 2, PCI DSS, and various industry standards require principle of least privilege. Rootless container technology makes compliance achievable without sacrificing the convenience of container-based deployment.

No setuid binaries — traditional Docker uses setuid-root binaries that are a well-known attack vector. RootlessKit, fuse-overlayfs, and slirp4netns operate entirely without setuid, reducing the attack surface of your container infrastructure.

For related reading, see our Rootless Container Runtimes comparison and OCI Container Runtimes deep dive.

FAQ

What is a rootless container?

A rootless container runs entirely under an unprivileged user account, without requiring root access or setuid binaries on the host. The container process appears as a normal user process to the host kernel, and any container escape is limited to the permissions of that unprivileged user.

Do I need to modify my applications to run them rootlessly?

No. Rootless containers run the same container images as rootful containers. The difference is entirely in how the container runtime sets up the execution environment. Your application code, Dockerfiles, and compose files work identically.

Is rootless container performance slower?

There is a small performance overhead, typically 5-15% depending on the workload. fuse-overlayfs adds I/O overhead due to the FUSE userspace boundary, and slirp4netns adds network latency compared to native veth pairs. For most self-hosted workloads (web services, databases, monitoring), this overhead is imperceptible.

Can I use rootless containers with Kubernetes?

Kubernetes itself requires root-level setup, but individual pods can run as non-root users using security contexts. For self-hosted single-node clusters, you can run the entire Kubernetes node in rootless mode using RootlessKit as the init process.

Which container runtimes support rootless mode?

Podman has first-class rootless support (it was designed rootless from the start). Docker supports rootless mode via dockerd-rootless.sh (since Docker 20.10). nerdctl (containerd’s CLI) also supports rootless operation. All three use RootlessKit, fuse-overlayfs, and slirp4netns under the hood.

How do I expose ports from rootless containers?

RootlessKit provides a built-in port forwarder (--port-driver=builtin) that maps host ports to container ports. Alternatively, slirp4netns can be configured with port forwarding rules. Both approaches work without root-level iptables configuration.

Are there any limitations with rootless containers?

Yes. Some features require root privileges and are unavailable in rootless mode:

• Cgroup v1 resource limits (cgroup v2 works with rootless)
• Certain network plugins (bridge, macvlan)
• Mounting block devices
• Setting real-time scheduling priorities
• Using privileged containers Most of these limitations can be worked around or are acceptable for typical self-hosted workloads.