linux - 在 chroot 下熔断符号链接(symbolic link)解析

Question

我正在创建一个与示例非常相似的基于熔断器的文件系统 passthrough_fh .在调用底层系统调用之前，我在我的处理程序中记录一些统计信息。

我将它与来自 d​​ebboostrap 的 debian Wheezy chroot 镜像一起使用。我的想法是将 wheezy/镜像到我的挂载点，然后一个进程将 chroot 到挂载点，所有事件都将通过我的 fuse fs 记录。

操作系统似乎可以很好地处理 chroot 路径解析。也就是说，如果 chrooted 进程执行 stat("/bin/ls") ，从我的 fuse 过程中我看到 stat("wheezy/bin/ls") .

但是我不确定如何处理符号链接(symbolic link)。例如文件
wheezy/lib64/ld-linux-x86-64.so.2
指向
/lib/x86_64-linux-gnu/ld-2.13.so

所以当我调用 stat("wheezy/lib64/ld-linux-x86-64.so.2")它不仅会起作用，因为操作系统会尝试取消引用符号链接(symbolic link) /lib/x86_64-linux-gnu/ld-2.13.so而不是正确的 wheezy/lib/x86_64-linux-gnu/ld-2.13.so .

这是一个简化的例子，我不能只在前面加上 wheezy/对于所有路径，我还想支持不 chroot 或多次 chroot 的应用程序。

我可以想到一些不太理想的方法来做到这一点，例如检查/proc/pid/root/在 chroot 的情况下获取进程的根目录，但是我必须始终检查文件是否是符号链接(symbolic link)。

有没有更好的方法或基于融合的文件系统处理这个问题的一般方法？

Answer 1

在联系了 fuse-devel 邮件列表后，我收到了如下回复:

If you are performing this stat(2) for GETATTR or LOOKUP, you should
be using lstat(2) instead. This will tell the kernel that you found a
symlink and it should keep managing path resolution correctly for you.

即在处理LOOKUP或GETATTR时使用lstat(2)，使用lstat的结果来填充fuse结构。从那里，内核将自动处理名称解析(即使是符号链接(symbolic link)和在 chroot 中运行的进程)。