容器里显示 root，手机就 Root 了吗？rootfs、chroot、PRoot 与 Rootless 容器图解

不会。这里的 root 多半是进程看到的根文件系统 /，或 user namespace 内映射出来的 UID 0；它不是 Android Bootloader 解锁，也不会安装 Magisk、KernelSU 或 APatch。本篇用一个退出即消失的 Linux namespace 实验，把“容器内 root”与“宿主权限”分开看清。

你会完成什么#

• 区分 root filesystem、namespace 内 UID 0、宿主 UID 0 与 Android Root。
• 用 unshare 创建只映射当前用户的临时 user namespace。
• 在 namespace 内外比较 id、uid_map 和测试文件所有者。
• 知道 PRoot、rootless Podman/Docker、rootful container 与 VM 的隔离差异。
• 退出实验并确认没有残留容器、挂载或特权配置。

先看结论#

心智模型#

宿主文件 owner UID 1000
        ↕ user-namespace 映射：外部 1000 ↔ 内部 0
容器/namespace 进程看到：UID 0 + 自己的 `/` 视图 + 受限 capabilities
        ✕ 不等于宿主 UID 0
        ✕ 不等于 Android Bootloader/boot image 已改变

工具清单#

项目全景：rootfs、容器与系统镜像的 43 个项目，一个不漏#

这 43 个项目横跨 Android/ChromeOS rootfs、镜像构建、可信启动、rootless 容器、服务器平台和少量明显同名误收录。主题应是“如何选择并验证一个 root 文件系统运行环境”。

1. Android、ChromeOS 与移动 rootfs · 13#

按 chroot、proot、原生 Docker、子系统 Root 与设备专用构建器区分宿主要求，先验证架构、内核特性和恢复入口。

本组共 13 项：11 个源项目、2 个 Fork，其中 3 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

2. rootfs 构建与多架构镜像 · 4#

从发行版 rootfs、initramfs/CPIO 到 QEMU 多架构调试，讲清输入、可复现构建、产物校验与不可直接刷入的边界。

本组共 4 项：4 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

3. 可启动、不可变与校验 root · 5#

把 ZFS root、NVMe 迁移、dm-verity/SquashFS 和桌面 rootfs 配置放进启动链路线，重点是备份、签名、引导项与回滚。

本组共 5 项：5 个源项目、0 个 Fork，其中 1 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

4. 非 root 容器、proot 与 sidecar · 9#

比较真正的非 root UID、容器内伪 root、proot 和无特权网络 sidecar；用最小镜像、只读挂载和能力清单做验收。

本组共 9 项：8 个源项目、1 个 Fork，其中 2 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

5. 容器平台与自托管运维 · 7#

把游戏服务器、服务网格、VPS 部署、可观测性与 homelab 管理工具串成部署生命周期，并区分“项目根仓库”与 root 权限。

本组共 7 项：7 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

6. 一次性隔离运行时与微虚拟机 · 3#

以 namespaces、Incus 和 Firecracker 类方案讲解如何给不可信任务临时 root，同时限制网络、持久化和宿主暴露。

本组共 3 项：3 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。

7. 同名词与误分类复核 · 2#

逐项标明剩余项目是 rootfs 工具、上层应用、仅叫 Roots/Rootspace，还是明显无关内容；保留目录覆盖但不建议执行。

本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。它们的平台、用途或分类存在边界，只作逐项核验，不当作默认安装候选。

开始前#

准备一台你拥有的 Linux VM 或桌面测试机，并确认有 unshare、id、stat、mktemp。本实验不需要 sudo；如果教程或系统提示必须加 sudo，先停下来检查是不是 user namespace 被禁用。记录开始时的 id 输出。不要在 Android 的 Termux 中照搬 unshare：手机内核和 SELinux 支持差异很大，Android 路线应使用 Termux 官方 proot-distro 文档。

操作步骤#

1. 建立可识别的宿主测试文件#

在普通终端运行 id，再用 mktemp -d 创建临时目录；把打印出的绝对路径记作 <lab-dir>。运行 touch <lab-dir>/outside.txt 和 stat -c '%u:%g %n' <lab-dir>/outside.txt，记录宿主看到的 owner。这里 <lab-dir> 必须替换成刚刚输出的具体路径，不能原样复制尖括号。

2. 进入临时 user namespace#

运行 unshare --user --map-root-user --mount-proc sh。新 shell 中执行 id、cat /proc/self/uid_map，然后 touch <lab-dir>/inside.txt 并用同一条 stat 查看。你可能在里面看到 UID 0；映射表应说明该 UID 对应外部的普通账户。不要尝试挂载宿主目录、修改网络或扩大 capability。

3. 退出并核对宿主视角#

在 namespace shell 输入 exit。回到原终端后再次运行 id，再对 <lab-dir>/inside.txt 执行 stat。宿主通常仍把它显示为你的普通 UID，而不是宿主 root。确认内容无用后，用文件管理器删除这个明确的临时目录，或只删除其中两个测试文件；不要对宽泛路径执行递归删除。这个退出动作就是回滚点，namespace 随最后一个进程结束。

验证#

• namespace 外的 id 始终是普通用户；只有临时 shell 内显示映射后的 UID 0。
• /proc/self/uid_map 明确记录了内外身份映射，而不是凭提示符猜测。
• namespace 内创建的文件从宿主看仍归你的普通 UID 所有。
• exit 后临时 shell 消失，没有后台容器或 daemon。
• Android 手机的 Bootloader、启动镜像和 Root 管理器完全没有发生变化。

排错#

完成清单#

• □我记录了宿主 UID 与 namespace 的 uid_map。
• □我能说明 rootfs / 是进程视图的起点，而不是权限证明。
• □我没有使用 privileged、Docker socket、宿主根目录或未知 rootfs。
• □我退出了 namespace，并从宿主核对测试文件所有者。
• □我能解释为什么容器内 UID 0 不等于 Android Root。

一手资料#

• Termux proot-distro
• Docker Rootless mode
• Podman manual
• OCI Runtime Specification
• Linux user namespaces manual
• Linux unshare manual