chroot仅改变进程根路径，不处理权限；bind mount通过挂载选项（如ro、noexec、nosuid）叠加控制访问，实现精准权限落地，并解决文件同步、空间占用与动态目录（如/proc）挂载问题。
chroot 本身不处理权限，它只改变进程看到的根路径；真正控制“谁能读写哪些文件”的，是 Linux 的权限体系。而 bind mount 是一种灵活的挂载方式，能把宿主机上的某个目录或文件，以指定权限映射进 chroot 环境中——这正是把权限管理精准落地的关键一环。
chroot 环境里为什么需要 bind mount？
单纯复制文件到 chroot 目录（比如 /mnt/jail）会导致几个问题：文件更新不同步、占用双份磁盘空间、无法共享动态内容（如 /proc、/dev）。bind mount 能让 chroot 内部“看到”宿主机上的真实路径，同时支持挂载选项控制访问行为，比如只读、noexec、nosuid 等。
- 挂载 /proc、/sys、/dev 是 chroot 正常运行的基础，否则 ps、lsblk、udev 等命令会失败
- 想让某个用户在 chroot 中只能读取配置，但不能修改？用
mount --bind -o ro /host/etc/myapp.conf /mnt/jail/etc/myapp.conf - 要防止 chroot 内程序执行危险脚本？挂载时加
noexec，例如mount --bind -o noexec,ro /host/shared/scripts /mnt/jail/opt/scripts
权限控制要分两层做
第一层是 chroot 外的原始文件权限（属主、属组、rwx），第二层是 bind mount 挂载时的选项限制。两者叠加生效，且挂载选项优先级更高。
- 即使源文件权限是 777，加上
ro后，chroot 里所有用户都只能读 - 即使源文件设置了 suid 位，加上
nosuid后，chroot 里执行该程序也不会提权 - 若需精细到单个用户，先用 chown/chmod 设置源文件权限，再 bind mount 进入环境，避免在 chroot 内重复授权
实用组合示例：限制用户仅能访问自己的配置
假设有一个服务用户 appuser，只允许它读取 /etc/app/config.yaml，但不能改也不能执行任何东西：
- 先确保源文件权限合理：
sudo chown root:appgroup /etc/app/config.yaml && sudo chmod 640 /etc/app/config.yaml - 把用户加入授权组：
sudo usermod -aG appgroup appuser - 构建 chroot 目录结构后，只挂载该文件：
sudo mount --bind -o ro, nosuid /etc/app/config.yaml /mnt/jail/etc/app/config.yaml - 启动时降权运行：
sudo chroot --userspec=appuser:appgroup /mnt/jail /usr/bin/myapp
注意 bind mount 的生命周期和安全边界
bind mount 是临时的，重启后消失；如需持久化，得写进 /etc/fstab，但要注意 fstab 中的挂载点必须在 chroot 目录内已存在，且挂载顺序不能错（比如 /proc 必须在 chroot 启动前挂好）。
- 不要 bind mount 整个 /home 或 /tmp 进去——这可能绕过 chroot 隔离，暴露其他用户数据
- 避免挂载父目录（如 /etc）后再挂载其子项（如 /etc/shadow），顺序或选项冲突可能导致不可预期行为
- chroot + bind mount 不等于容器，它不隔离 PID、网络或用户命名空间，敏感操作仍需配合 sudoers、SELinux 或 cgroups 使用
