Running Podman Rootless on Linux: Why User Namespaces Matter and How to Verify

Problem

Many developers want to run containers on a shared Linux host without granting themselves or the application full root privileges. A common pain point is that the default Podman installation on most distributions launches containers as root, exposing the host to potential security risks. The question is: can we run Podman safely as a non‑privileged user while still having the full container experience?

Thesis

Podman’s rootless mode leverages Linux user namespaces to map container users to unprivileged host UIDs/GIDs. This lets unprivileged users spin up, run, and manage containers without a daemon, while keeping the host isolated. However, rootless containers come with networking constraints, build‑time differences, and subtle permission quirks that must be understood and verified.

Rootless Setup – What You Need

Before you can run rootless containers, the host must allow unprivileged user namespaces and provide a UID/GID range for the user. The following steps confirm and prepare the environment.

1. Check kernel support

   # cat /proc/sys/kernel/unprivileged_userns_clone
   

   A value of 1 means the kernel permits user namespaces for unprivileged users. If you see 0, you must enable it in /etc/sysctl.conf or contact your system administrator.

2. Allocate UID/GID ranges

   # grep $(whoami) /etc/subuid
   # grep $(whoami) /etc/subgid
   

   Both files should list a range of at least 65536 consecutive UIDs and GIDs. If they’re missing, add an entry like:

   $(whoami):100000:65536
   

   Then run newgrp or log out/in to refresh the mapping.

3. Verify rootless status

   # podman info | grep -i rootless
   

   The output should include security.rootless: true and a storage driver such as overlay or overlayfs that supports user namespaces.

Networking & Port Binding

Rootless containers cannot bind to host ports below 1024 directly because non‑root users lack the capability to listen on privileged ports. Two common workarounds are:

• Port forwarding via slirp4netns – the default user‑mode network stack used by Podman. It forwards container ports to high‑numbered host ports automatically.

  # podman run --rm -p 8080:80 nginx
  

  Access the container at http://localhost:8080.

• Lowering ip_unprivileged_port_start – adjust the kernel parameter to allow binding to ports <1024.

  # sysctl -w net.ipv4.ip_unprivileged_port_start=1024
  

  After this change, you can bind to 80 directly:

  # podman run --rm -p 80:80 nginx
  

  Be aware that this broadens the attack surface for all unprivileged users.

For most workloads, slirp4netns is sufficient and keeps the host safe. It introduces a small latency penalty and does not support advanced iptables rules.

Image Build & Storage Drivers

Rootless builds rely on overlay filesystems that support user namespaces. Two options exist:

• overlayfs – native kernel support; faster but requires a recent kernel (≥4.18) and a filesystem that supports the userns flag.
• fuse-overlayfs – FUSE‑based overlay that works on older kernels but is slower, especially for many small files.

Check the storage driver by inspecting podman info:

# podman info | grep storage

When building images, use the --build-arg flag to avoid hard‑coded root paths that might clash with the UID mapping.

Worked Example – Verify User Namespace Mapping

Run a simple container that prints its effective UID/GID inside the container. This demonstrates that the mapping works without root privileges.

# podman run --rm -u 1000:1000 alpine id

Expected output (no output is provided here, but you should see a UID/GID of 1000 inside the container). If the command fails or shows root, the UID mapping is broken.

To confirm the mapping, inspect the host side:

# cat /proc/self/status | grep Uid

The first number is the real UID, the second the effective UID. They should match the container’s UID.

Limitations & Trade‑offs

• Capabilities – Some capabilities (e.g., CAP_SYS_ADMIN) are dropped in rootless mode, which can break workloads that rely on them.
• Device Access – Devices such as /dev/net/tun are not automatically available; you may need to bind‑mount them explicitly.
• Volume Ownership – When mounting host directories, the container’s UID may not match the host owner, leading to permission errors. Use --userns=keep-id or adjust ownership in the host directory.
• Performance – Fuse‑overlayfs is slower than native overlay, especially for large image layers or frequent filesystem operations.

Actionable Checklist

1. Confirm /proc/sys/kernel/unprivileged_userns_clone is 1.
2. Ensure /etc/subuid and /etc/subgid contain a 65536‑range entry for your user.
3. Run podman info to verify security.rootless: true.
4. Test a simple container with podman run --rm -u 1000:1000 alpine id.
5. If you need to bind to ports < 1024, decide between slirp4netns or lowering ip_unprivileged_port_start.
6. Choose an appropriate storage driver: overlay for performance, fuse-overlayfs for older kernels.
7. Use podman generate systemd to create systemd units for long‑running rootless services.
8. Document any capability or device restrictions that might affect your workloads.

By following this checklist, you can confidently run Podman in rootless mode, maintain a secure host environment, and understand the trade‑offs involved.