我想知道是否可以编写一个 shell 脚本：
为给定的用户规范和组运行 chroot
监视/拦截所有启动的进程的系统调用，以及它们调用的库试图加载，如果文件在 chroot 路径中不可用，但在“正常”系统路径中可用，则不会访问失败，而是让他们访问 chroot jail 之外的原始位置中的丢失文件，并将此事实记录到日志文件中。
例如，进程尝试启动 /bin/ls，但它不在 chroot 路径中。系统调用钩子计算出这一点，并注意到 /bin/ls 确实存在于主系统 /bin 路径中，因此该文件被缓存到用户的 chroot 中并被记录下来。
一旦用户退出，并注意到丢失的文件，就会创建一个脚本，允许在下次该用户使用 chroot 命令时包含丢失的文件。
你的想法是，你可以用它来“测试”一个设置，并制作用于正常使用的实际 chroot 监狱，而不是通过反复试验。
它的优点是（假设你从一个“空”的监狱开始，确切地知道哪些文件是已知并已做好未来使用的准备。
我认为“实时”系统没有理由不能以这种方式代理文件调用，但是它需要得到良好的监控。我怀疑由于所有的监控，它会变得非常慢，所以你不会想长期这样运行，但你可以设置一个阈值，在这个阈值上，一个不需要代理文件 x 次重启的进程将迁移到非监控版本，这将提高性能。
存在这样的事物吗？如果没有，人们会用什么工具来构思这样的概念？
答案1
需要是发明之母……我在胡思乱想并做了一些与我所描述的类似的东西之后，回答了我自己的问题
这是我的发明之母
https://github.com/jonathan-annett/chroot-node-app
尽管 ldd 可以很好地识别给定可执行文件所需的库，但它并没有考虑到根据可执行文件本身在运行时做出的决定而加载的库。例如，ping 似乎需要一些 ldd 无法检测到的额外库。
所以我设计了一个系统，让您可以使用命令行上的 strace 运行给定的应用程序，并将输出保存到 chroot 环境中的日志文件。外部另一个脚本会解析该日志并找到丢失的文件并将它们放在正确的位置，然后将额外的文件添加到原始构建列表中。