Running Unprivileged Workloads with Podman Rootless Containers and Systemd

Why Run Containers Unprivileged?

When a container runs as root on a host, a compromise inside the container can give an attacker full control over the host. Podman eliminates this risk by never launching a long‑lived privileged daemon. In rootless mode, every container is a child of the user’s shell, and the container’s root user is mapped to an unprivileged UID on the host via Linux user namespaces. This means a breakout stays inside the user’s namespace and cannot touch system files or other users’ containers.

Rootless Podman on a Typical Linux Desktop

Most modern distros ship Podman 4.x or later, which fully supports rootless operation. The prerequisites are simple:

• Sub‑UID and sub‑GID ranges for your user in /etc/subuid and /etc/subgid (the installer usually adds them).
• cgroup v2 enabled on the host (most recent kernels do).
• Either slirp4netns or the newer pasta networking backend installed.

Verify the setup:

podman info | grep -E "rootless|cgroup v2|networking"
# Expected: rootless: true, cgroup version: 2, networking: pasta (or slirp4netns)

Systemd Integration – Quadlet Units

Podman can expose each container as a systemd user unit without a daemon. Create a .container file in ~/.config/containers/systemd (the directory is created automatically). The unit starts when you log in and restarts on failure. For services that need to survive logout, enable lingering with loginctl enable-linger $USER.

[Unit]
Description=Rootless Nginx Service
After=network-online.target

[Service]
ExecStart=/usr/bin/podman run --rm -p 8080:80 --name nginx-demo nginx:latest
ExecStop=/usr/bin/podman stop nginx-demo
Restart=on-failure

[Install]
WantedBy=default.target

Save the file as nginx-demo.container, then reload systemd:

systemctl --user daemon-reload
systemctl --user enable nginx-demo
systemctl --user start nginx-demo

Check status:

systemctl --user status nginx-demo

Now the service is managed by systemd, no daemon running, and still rootless.

Practical Example – Deploy a Rootless Nginx Pod

Pods let multiple containers share networking and optionally IPC/UTS namespaces. They are a natural bridge to Kubernetes.

# Create a pod that listens on 8080
podman pod create --name web-pod -p 8080:80

# Run Nginx inside the pod
podman run -d --pod web-pod --name nginx nginx:latest

# Verify mapping: the container’s root maps to a low UID
podman top nginx -o pid,user,group
# The  column will show a UID like 100000, not 0

Expose the pod as a systemd unit using Quadlet:

[Unit]
Description=Rootless Nginx Pod
After=network-online.target

[Service]
ExecStart=/usr/bin/podman pod start web-pod
ExecStop=/usr/bin/podman pod stop web-pod
Restart=on-failure

[Install]
WantedBy=default.target

Reload and enable:

systemctl --user daemon-reload
systemctl --user enable --now nginx-pod

Open http://localhost:8080; you should see the Nginx welcome page. The pod remains active across logouts if lingering is enabled.

Trade‑Offs and Limitations

• Port binding: In rootless mode you cannot publish ports below 1024 without adjusting net.ipv4.ip_nonlocal_bind or using a privileged helper. For most web services, high ports (e.g., 8080) are sufficient.
• Networking performance: slirp4netns and pasta add a small overhead compared to host networking. Throughput‑critical workloads may prefer rootful mode or host networking.
• Volume mounts: Bind mounts of host paths require the target directory to be owned by the UID range used by the container. Otherwise the mount fails.
• Feature parity: While Podman’s CLI is Docker‑compatible, Docker Compose is not directly supported; use podman compose or podman‑compose for multi‑container setups.

Actionable Takeaway

Rootless Podman gives the safety of user namespaces without sacrificing the convenience of containerized workloads. By pairing it with systemd Quadlet units, you get daemonless services that start on login, restart on failure, and survive logouts when lingering is enabled. The example above shows how to spin up an Nginx pod, expose it via a systemd unit, and verify that the container’s root is mapped to an unprivileged UID. For production workloads, evaluate networking and volume requirements, and consider whether a rootful or host‑networked approach is necessary for performance.