chroot下熔断符号链接解析答案

【问题标题】：Fuse symbolic link resolution under chrootchroot下熔断符号链接解析
【发布时间】：2019-01-23 22:17:56
【问题描述】：

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

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

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

但是我不确定如何处理符号链接。例如文件
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") 时，它不会正常工作，因为操作系统会尝试取消引用符号链接/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的情况下获取进程的根，但是我必须始终检查文件是否是符号链接。

基于 fuse 的文件系统是否有更好的方式或通用方式来处理这个问题？

【问题讨论】：

标签： linux fuse chroot

【解决方案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 struct。从那里，内核将自动处理名称解析（即使对于符号链接和在 chroot 中运行的进程）。

【讨论】：