使用 NFSv4 fsid=0 并将 NFS 根导出到整个 LAN（或不导出）的影响

Question

在NFSv4的教程是经常可以看到的建议，一个共享的根目录导出到类似于整个子网这从拱门维基：

/etc/出口：

/srv/nfs        192.168.1.0/24(rw,sync,crossmnt,fsid=0,no_subtree_check)
/srv/nfs/music  192.168.1.0/24(rw,sync,no_subtree_check)
/srv/nfs/public 192.168.1.0/24(ro,all_squash,insecure,no_subtree_check) desktop(rw,sync,all_squash,anonuid=99,anongid=99,no_subtree_check)

根本没有第一行会更安全吗？（在我的问题中，当我提到“第一行”时，我指的是上面代码段中的第一行导出行。）

在 NFSv4 中，fsid=0 是可选的，它似乎主要是为了方便缩短路径（通过将 /srv/nfs 转换为 /）。在我的初步测试中，只要您使用 /srv/nfs，导出就可以在没有第一行的情况下正常工作。第一行提供哪些重要功能（如果有）？

当我们知道至少还有一个像这样的绑定安装时，我还想考虑这个例子：

/srv/nfs/projects

（假设与音乐绑定安装不同，“项目”的内容是敏感的。）

第一个导出行，正如上面所写的，似乎让 LAN 上的每个客户端都可以访问整个导出的文件系统，尤其是使用 crossmnt 和 no_subtree_check。我并不是建议忽略所有者和组权限，但我认为导出在没有第一行的情况下也能正常工作，并且其他绑定安装在 /srv/nfs 下（例如 /srv/nfs/projects）不会对整个子网不必要地开放，从而暴露有关所有者和组权限的任何潜在疏忽。

当然，可以添加类似于此正确共享“项目”的导出：

/etc/出口：

/srv/nfs/projects 192.168.1.123(rw,sync,root_squash,subtree_check)

这条新线路是否受到第一条线路的任何影响？我看不出第一条出口线是如何起到任何重要作用的。

如果这条线有帮助或推荐，那么做这样的事情是否明智？

/srv/nfs        192.168.1.0/24(ro,sync,fsid=0,subtree_check,all_squash)

接下来的更具体的导出将覆盖这个导出是否正确？例如，即使第一行更改为 ro 并使其更具限制性（如下例所示），以下行是否会正确授予对“音乐”的 rw 访问权限？

/srv/nfs        192.168.1.0/24(ro,sync,fsid=0,subtree_check,all_squash)
/srv/nfs/music  192.168.1.2(rw,sync,no_subtree_check)

列出出口的顺序重要吗？什么决定优先级？更具体的地址（例如，192.168.1.2）是否会覆盖更通用的地址（192.168.1.0/24）？

注意：这个问题有一个重点主题，它可能会使用更好的标题来说明这一点，但到目前为止我还没有想出正确的标题。我欢迎编辑。

Answer 1

导出的手册页介绍了该fsid参数

NFS 需要能够识别它导出的每个文件系统。通常它会使用文件系统的 UUID（如果文件系统有这样的东西）或保存文件系统的设备的设备号（如果文件系统存储在设备上）。

由于并非所有文件系统都存储在设备上，并且并非所有文件系统都有 UUID，因此有时需要显式告诉 NFS 如何识别文件系统。这是通过fsid=选项完成的。

现在我们知道为什么fsid有时需要该参数，让我们看看手册页中有关 NFSv4 的内容（这部分与旧版本有很大不同）：

对于 NFSv4，有一个独特的文件系统，它是所有导出文件系统的根。这与fsid=root或fsid=0两者指定的含义完全相同。

换句话说，对于 NFSv4，示例中的第一行定义一个基点，服务器导出到某个客户端的所有目录都位于该基点下。乍一看，与允许导出任何目录的 NFSv3 的灵活性相比，这听起来像是倒退了一步。但是，您可以轻松地将已在其他位置安装的目录放入此目录中。只需添加如下一行即可/etc/fstab

/path/to/music/dir /srv/nfs/music none rbind 0 0

并运行mount -a以挂载新的文件系统。新方法本质上充当伪根文件系统，防止客户端访问该目录之外的数据，从而允许 NFS 服务器轻松检查是否应授予客户端访问文件的权限，从而降低复杂性，同时提高安全性。