chroot 不提供真正安全隔离，仅适用于非特权进程路径隔离或系统修复；常见错误是缺少 bash 依赖库，需用 ldd 查看并复制对应 .so 文件，或用 debootstrap/dnf 构建完整环境，同时挂载 /proc /dev /sys 并配置 /etc/resolv.conf 等网络文件。
Chroot 本身不提供真正的安全隔离，不能防御 root 权限逃逸，仅适合非特权进程的轻量路径隔离或系统修复场景。
chroot 命令执行失败：报错 chroot: failed to run command '/bin/bash': No such file or directory
这是最常见问题，本质是 chroot 环境缺少目标程序及其依赖的动态库。即使复制了 /bin/bash，它仍依赖 libc.so.6 等共享库，而这些库通常在 /lib64 或 /lib 下。
- 用
ldd /bin/bash查看所有依赖库路径 - 手动创建对应目录结构（如
lib64），再用cp复制所需.so文件（注意软链接要转为真实文件或同步复制） - 更稳妥的方式是用
debootstrap（Debian/Ubuntu）或dnf --installroot（RHEL/CentOS）构建完整基础环境，而非手动拼凑 - 别忽略
/dev、/proc、/sys—— 启动 shell 前需先挂载：mount -t proc proc /path/to/chroot/proc
进入 chroot 后无法解析域名或访问网络
chroot 不隔离网络命名空间，但默认不带 /etc/resolv.conf 和 /etc/nsswitch.conf，导致 DNS 查询失败或用户/组查不到。
- 手动拷贝宿主机的
/etc/resolv.conf到 chroot 环境的/etc/目录下 - 检查
/etc/nsswitch.conf是否存在；若缺失，至少确保有hosts: files dns行 - 若需完整网络功能（如 SSH），还需复制
/etc/hosts、/etc/services等基础配置 - 注意：chroot 内运行的服务仍使用宿主机的网络栈，端口冲突、防火墙规则等照常生效
误以为 chroot 能限制 root 权限，结果被逃逸
只要进程在 chroot 内拥有 root 权限，就能通过 chroot + chdir + openat 等组合绕过路径限制；Linux 2.6.26+ 已禁止非特权用户调用 chroot，但 root 用户始终可以退出。
- chroot 不是容器，无 PID、network、mount、UTS 等命名空间隔离
- 真正需要安全隔离，请直接用
systemd-nspawn、podman unshare或docker run --cap-drop=ALL - 若仅用于紧急修复（如重装 GRUB、重置密码），务必在操作完成后立即退出并卸载临时挂载点（
umount -R /path/to/chroot） - 切勿在生产环境中用 chroot 运行长期服务（如 web server），这等于裸奔
chroot 的脆弱性不在实现，而在设计初衷——它本就不是安全机制。真正容易被忽略的是：很多人复制完 bash 和几个库就以为“进去了”，却没验证 id、mount、ls /proc/1/ns 这些命令是否正常，而这恰恰暴露了它毫无隔离深度的事实。
