2.1 什么是用户命名空间#

用户命名空间允许一个进程在「自己的小世界」里拥有独立的 uid/gid 视图：进程在命名空间内看自己是 uid 0（root），但在宿主机真实视角里，它只是一个普通用户，比如 uid 1000。

Rootless Docker 启动时，会为当前普通用户创建一个用户命名空间，dockerd 和它管理的所有容器都活在这个命名空间里面。于是：

• 容器里你看到的 root，是假的 root，只在命名空间内有效
• 这个假 root 对应到宿主机，是运行 dockerd 的那个普通用户
• 容器内进程对宿主机文件、进程的访问权限，按普通用户计算，碰不到别人的东西

2.2 subuid 与 subgid：映射的原材料#

问题来了：容器镜像里常常不只有 root 一个用户，还有 uid 1、33、999 等各种系统账号。这些 uid 在命名空间里也要有位置，总不能全挤到同一个宿主机 uid 上。

解决办法是 /etc/subuid 和 /etc/subgid。系统会给每个普通用户分配一段从属 uid 范围，默认每人 65536 个，写在文件里长这样：

1
anex:100000:65536

含义是：用户 anex 可以使用宿主机 uid 100000 到 165535 这一段，用来映射命名空间内的 uid。映射关系大致如下：

实际完成这段映射设置的，是 newuidmap 和 newgidmap 两个带 setuid 的小工具，它们由 uidmap 软件包提供，这也是后文安装前置依赖里必须有它的原因。

一句话总结原理：Rootless 不是把权限做小了，而是把容器里的 root 翻译成了宿主机上的普通人。

WARNING

用户命名空间本身也曾出过本地提权漏洞，所以 rootless 是「多一层隔离」，不是「绝对安全」。宿主机内核要保持更新，这个前提在任何模式下都成立。

3.1 前置依赖#

先装齐依赖，缺一个后面都会卡：

1
sudo apt update
2
sudo apt install -y uidmap dbus-user-session slirp4netns fuse-overlayfs

逐个说明它们干什么：

确认 subuid 已分配：

1
grep "^$(whoami):" /etc/subuid /etc/subgid

正常会输出两行各 65536 的范围。如果为空，用下面命令手动补（把 anex 换成你的用户名）：

1
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 anex

再确认内核允许普通用户创建用户命名空间（Debian 默认允许，个别加固过的系统会关）：

1
sysctl kernel.unprivileged_userns_clone
2
# 期望输出 1；若为 0：
3
sudo sysctl -w kernel.unprivileged_userns_clone=1

3.2 取得安装脚本#

Rootless 模式的安装脚本随 Docker 官方静态包分发，也在官方仓库里提供。最稳妥的路径是装好官方源之后，用包管理器安装 rootless 扩展包：

1
sudo apt install -y docker-ce-rootless-extras

装完后，当前用户目录下可直接调用脚本（注意：不要加 sudo，全程用普通用户执行）：

1
dockerd-rootless-setuptool.sh install

脚本会自动做这些事：检查依赖与 subuid、生成 ~/.config/docker/daemon.json、写入用户级 systemd 单元 ~/.config/systemd/user/docker.service、把 DOCKER_HOST 的提示打在输出末尾。

3.3 配置环境变量并启动#

Rootless 的 socket 不在 /var/run/docker.sock，而在用户自己的运行时目录里。把这两行加进 ~/.bashrc（或你用的 Shell 配置文件）：

1
export PATH=/usr/bin:$PATH
2
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock

重新登录或 source ~/.bashrc 后，用用户级 systemd 启动和管理：

1
systemctl --user start docker
2
systemctl --user enable docker
3
systemctl --user status docker

验证一把：

1
docker info | grep -i rootless
2
docker run --rm hello-world
3
docker run -d --name web -p 8080:80 nginx
4
curl http://127.0.0.1:8080

docker info 里能看到 rootless 字样、且 hello-world 与 Nginx 都正常，就装好了。日常命令和标准 Docker 完全一致，docker ps、docker compose up -d 该怎么用还怎么用。

3.4 让退出登录后服务不死：enable-linger#

用户级 systemd 有个默认行为：用户最后一个登录会话退出后，它的用户服务会被一并停掉。服务器场景这显然不行，容器必须常驻。解决办法是给该用户开启 linger：

1
sudo loginctl enable-linger anex
2
loginctl show-user anex | grep Linger
3
# 输出 Linger=yes 即生效

开启后，即使 SSH 断开、用户完全退出，systemctl --user 管理的 Docker 和容器也会继续运行，开机后也会自动拉起。这一步漏掉的话，会出现「一退出 SSH 容器全没了」的灵异现象，务必在交付前检查。

5.1 fork/exec 模型#

Podman 由红帽主导开发。它的命令直接以当前用户身份 fork/exec 出容器进程，没有一个常驻的、权限很高的中间人：

• 你是谁，容器就以谁的权限跑，天然默认 rootless
• podman 进程执行完就退出，不留常驻进程，攻击面随之消失
• 也提供了一个可选的 podman.socket 兼容接口给工具调用，但那是按需的，不是必需品

这带来的直接好处是和 systemd 的集成非常自然：容器就是普通进程，systemd 可以直接管它的生命周期、日志和重启，不需要再套一层守护进程去对接。

5.2 Pod 概念与 Kubernetes 的渊源#

Podman 有一个 Docker 没有的一等概念：Pod。一个 Pod 里可以放多个容器，它们共享同一个网络命名空间，也就是共享 IP 和端口空间、可以互相用 localhost 访问。

这个概念正是从 Kubernetes 借来的——Kubernetes 里最小的调度单位就是 Pod。于是 Podman 多了一条独特的工作流：本地用 Podman 把一组容器跑顺之后，可以用 podman generate kube 把它导出成 Kubernetes 的 YAML，再拿去集群里部署；反过来也能 podman play kube 直接按 YAML 起容器。对有朝一日要碰 Kubernetes 的人，这条桥很顺手。

5.3 与 systemd 集成：从 generate systemd 到 Quadlet#

老办法是生成 systemd 单元文件：

1
podman generate systemd --name web --files --new

它会吐出一个 .service 文件，放进用户或系统的 systemd 目录后，就能用 systemctl 管理容器启停。需要注意：generate systemd 在新版本 Podman 里已经标记为不推荐继续使用，官方主推的是 Quadlet。

Quadlet 的写法是声明式的：你写一个 web.container 文件，描述镜像、端口、卷，长这样：

1
[Container]
2
Image=nginx:latest
3
PublishPort=8080:80
4

5
[Service]
6
Restart=always
7

8
[Install]
9
WantedBy=default.target

把它放到 ~/.config/containers/systemd/，执行 systemctl --user daemon-reload 后，systemd 会自动生成对应的服务，之后 systemctl --user start web 即可。配置即代码、开机自启、日志进 journal，一套全齐，这是目前 Podman 官方推荐的常驻服务方式。

9.1 Rootless Docker 装完起不来，先查 XDG_RUNTIME_DIR#

典型报错是启动时提示找不到运行时目录或 socket 路径异常。多见于没通过正常登录会话、直接用 su 切用户或在某些 cron / 脚本环境里执行。

排查顺序：

1
echo $XDG_RUNTIME_DIR
2
# 应输出 /run/user/1000 这类路径，为空就是问题所在
3
ls -ld /run/user/$(id -u)
4
systemctl --user status docker
5
journalctl --user -u docker -n 50

XDG_RUNTIME_DIR 为空时，先退出去、用正常方式重新 SSH 登录该用户再试；仍不行，检查 pam_systemd 是否正常工作、以及该用户的 linger 是否已开。

9.2 端口绑不上：permission denied 或对外不通#

分两种情况：

1
# 情况一：绑 80/443 直接报权限错误
2
sysctl net.ipv4.ip_unprivileged_port_start
3
# 输出 1024 说明特权端口下限没放宽，按第四节处理，或改走高位端口加反代
4

5
# 情况二：容器起来了但外部访问不通
6
docker port web
7
curl -v http://127.0.0.1:8080
8
ss -tlnp | grep 8080

本机 curl 不通先看容器本身和端口映射；本机通、外网不通，再查宿主机防火墙与云厂商安全组，这与 rootless 无关，别在容器里绕圈子。

9.3 systemd 用户服务一退出登录就停#

症状非常典型：人一断开 SSH，容器全停；重新登录后服务显示 inactive。这就是 linger 没开：

1
loginctl show-user $(whoami) | grep Linger
2
# Linger=no 就是它
3
sudo loginctl enable-linger $(whoami)
4
systemctl --user enable docker
5
systemctl --user start docker

顺手确认 docker.service 是用户级单元而不是系统级：文件应在 ~/.config/systemd/user/docker.service，命令也始终是 systemctl --user，漏了 --user 会打到系统级 systemd 上，报找不到单元。

9.4 Podman 侧两个常见小问题#

拉镜像报 short-name 未解析，是因为 Podman 默认要求完整镜像名。把 nginx 写全为 docker.io/library/nginx 即可，或在 /etc/containers/registries.conf 里配置 unqualified-search-registries。

普通用户跑容器时存储报错、提示 overlay 挂载失败，一般是内核或发行版不支持 rootless overlay，切到 fuse-overlayfs 即可，在 ~/.config/containers/storage.conf 里把 driver 改为 overlay 并确保已装 fuse-overlayfs，或直接使用 vfs 先跑通（性能最差，只作临时验证）。