Chroot 允许我们更改根目录，或者更确切地说是特定进程的根目录。现在显然这确实将进程限制为指定的树（除非它不放弃特权）。
但我想知道在这种情况下还会出现哪些其他限制。特别是关于对设备和其他资源的访问。显然，前提是该进程不会 chroot 回到原始树中。
在我看来，如此巨大的变化应该会对系统功能产生进一步的影响。但我找不到任何具体的东西。
也许没有，但这似乎不太可能，我仍然更愿意确切地知道。
答案1
从功能上来说，没什么。从字面上看，该chroot()调用所做的只是更新内核为进程锚定路径解析的位置。特别是，除非您也放弃 root 权限，否则您仍然可以访问/proc并且/sys（因为您可以进行适当的mount()系统调用，不需要外部二进制文件），您仍然可以访问设备节点（您可以mknod()再次使用系统调用创建它们）不需要外部二进制文件），并且确实可以完成您可以想象的所有其他操作。
如果您在进入 chroot 后立即放弃 root 权限（就像大多数表现良好的应用程序所做的那样），您仍然可以从切换到的用户上下文中执行任何您可以执行的操作，前提是您不需要任何外部程序或库。不在 chroot 环境中。
但请注意，即使如此，chroot 本身的实际安全价值几乎为零。其实是真的通过各种机制轻松逃脱 chroot（说真的，只需在您最喜欢的搜索引擎上搜索“escape from chroot”，您就会发现结果列出了至少六种方法）。在任何任意应用程序中利用此漏洞所需的只是 ACE 漏洞。事实上，chroot()它最初根本不是为了安全而设计的，它曾经是（现在仍然是）一个开发人员工具，旨在允许在隔离环境中测试新软件（除其他外，现在它更常用于在自动化构建和 CI 系统）。
答案2
访问设备：除非 chroot 环境包含其自己的必要设备节点的副本，否则将无法访问。例如，您可能会发现，如果/dev/nullchroot 环境中没有设备节点，则 chrooted 交互式 shell 可能会表现得很奇怪。
chroot 环境中的进程也将无法发送 syslog 消息，除非您将 syslog 守护进程配置为/dev/log在 chroot 环境中创建附加进程。
如果/proc和/sys文件系统尚未在 chroot 环境中绑定安装或以其他方式提供，则使用它们的任何系统状态查询工具都将无法工作。