哇！多么好的承接。这只能意味着我们为了又一篇“系统管理员专栏”再次聚首。您可能还记得，我们上次讨论的是 NFS 文件共享。我称之为网络文件共享的鼻祖。然后，我们研究了基本设置以及导出文件系统以挂载到远程系统。/etc/exports 文件的基本格式如下所示

     /name_of_dir    client_name(permissions)

     /mnt/data1         192.168.1.2(rw,no_root_squash)

换句话说，允许 IP 地址为 192.168.1.2 的计算机将此目录挂载到任何位置，然后，即使作为 root 用户，也允许读写权限。正如我所提到的，默认是将 root 用户视为匿名用户，从而严重限制其访问权限。这就是我今天想要继续讨论的内容：NFS 世界中的安全性。在上面的示例中，我假设我作为系统管理员，是所有机器的 root 用户。我信任我自己。但是，信任必须谨慎对待。

在上期专栏发表后，一位读者（在文章末尾的评论表单中）询问是否可以导出 home 目录，以便用户无论从哪个工作站登录，都可以访问相同的桌面、电子邮件或数据。对于这位匿名读者的问题，答案是“是的”。这是 NFS 的一个非常常见的用途。然而，要充分回答这个问题，意味着我们应该比上一期专栏更详细地考虑权限。不幸的是，权限是 NFS 变得相当棘手的地方。

权限（或安全性）部分的选项包括 secure、ro、rw、sync、no_wdelay、nohide 和 no_subtree_check。还有另一组与个人用户的处理方式相关的权限。我喜欢将这些权限视为压缩权限，原因您很快就会在我说出它们的名字时明白。当然，这只是我个人的看法，而且我一直以（我应该怎么说呢？）我自己的特殊方式来表达事物。这些压缩权限是 root_squash、no_root_squash、all_squash、anonuid 和 anongid。

好的...一些细节；secure 意味着 NFS 挂载请求必须来自 1024 以下的互联网端口号。这是默认设置。如果您不希望这样，请指定 insecure。

接下来，我们有 ro 或 rw。如果您选择 ro，则导出的目录设置为只读访问。由于这是默认设置，您必须指定 rw 才能允许读写访问。继续我们的下一个权限选项 sync，我们有一个可以说是喜忧参半的选项。它的作用是确保每次写入操作后都进行数据提交。这在您的服务器崩溃的情况下非常有用，但代价是会稍微降低性能。顺便说一下，默认值是 async，这意味着系统只是写入，而不会担心操作是否完成就继续进行。与 sync 选项类似的是 no_wdelay，我们的下一个竞争者。如果您认为您的数据相对安全（但您仍然想要提交选项），您可以覆盖默认值 wdelay，并选择设置此选项，该选项允许系统同时进行多次提交，而不是延迟下一次写入，直到第一次提交完成。

假设您在同一树中导出了两个目录。如果其中一个目录在第一个目录之下，那么通常您会在客户端上同时挂载这两个目录，这是有道理的。如果您只挂载了父目录，您会看到第二个目录，但其下没有任何数据。它是隐藏的，对吗？现在，如果您想让整个子树也可见，请使用 no_hide 选项。但是，请谨慎使用它，因为已知客户端在此选项中存在奇怪的重复 inode 问题。正如您可能猜到的那样，默认选项是 hide。同样，我们有最后一个非压缩权限 no_subtree_check。这是另一个与子目录相关的选项。如果您导出的目录实际上是文件系统的子目录，那么上面的目录可能对权限有一些说法。由于您只能访问导出的文件和目录，因此必须进行检查以确保整个链的安全性。默认是允许 subtree_check，这可能具有轻微的安全隐患。如果这是一个问题，请记住指定 no_subtree_check。

现在，是期待已久的压缩权限。通常，这些权限与服务器如何处理用户 ID (UID) 和组 ID (GID) 在分配权限时遇到的问题有关；这就是 NFS 经常让人们感到困惑的地方。这里要记住的是，在默认安装中，NFS 通过假设服务器和客户端上的 UID 和 GID 是相同的来处理权限。如果您是设置所有机器、定义规则并确保所有机器都具有相同的 /etc/passwd 文件的人，那么这没什么大不了的。不幸的是，情况并非总是如此。当服务器上的用户“natika”的 UID 为 505，但客户端上的“natika”的 UID 为 501 时，真正的问题就开始了。

处理此问题的一种方法是运行一个名为“NIS”的程序，它代表 Network Information Service（网络信息服务）。我们将在以后的专栏中介绍如何设置 NIS 服务器。另一种方法是更改 NFS 在处理挂载请求时的默认行为。还记得我之前提到的 no_root_squash 挂载示例吗？这里再次展示。

     /mnt/data1         192.168.1.2(rw,no_root_squash)

当用户尝试访问远程 NFS 目录时，UID 和 GID 会被视为在客户端和服务器上是相同的，除非您是 root 用户。出于安全原因，NFS 将 root 用户的 UID (0) 映射到匿名用户或“nobody”。这是默认的 root_squash 选项。如果您是 NFS 域的管理员并且是所有机器的 root 用户，这可能不是问题，并且您可能希望 root 用户对导出的目录具有相同的权限。您还可以执行 all_squash 并覆盖默认的 no_all_squash，正如您可能预期的那样，这意味着所有 UID 都应被视为 root 用户，并将它们映射到匿名用户。最后，如果您想指定这个神秘的匿名用户，请使用 anonuid 或 anongid，或两者都使用。这允许您指定匿名用户的 UID 和 GID，root_squash 或 all_squash 会将权限映射到该用户。

请看以下示例。

     # /etc/exports file
     # These are just comments
     #
     /mnt/data1              natika(rw,no_root_squash)
     /usr/local              speedy(rw)
     /mnt/acctng             *.mycompany.com(rw)

前三行（以“#”符号开头）只是注释。/mnt/data1 行将使该目录可供名为“natika”的客户端使用。它还将允许 root 用户在此目录中被视为 root 用户。第二行允许名为“speedy”的客户端具有读写访问权限，但将 root 用户的 UID 映射到匿名用户。最后，第三行允许“mycompany.com”域中的任何计算机挂载 /mnt/acctng 目录，并具有读写访问权限。

现在我们已经设置了所有这些权限并处理了所有导出，远程系统上的人如何知道哪些目录可用于挂载（除非专门询问您）？使用 showmount 命令，我们可以找出任何给定服务器导出了哪些目录，如下所示

     [mgagne@testsys mgagne]$ /usr/sbin/showmount --exports 192.168.22.2
     Export list for 192.168.22.2:
     /data1     192.168.22.100
     /mnt/cdrom 192.168.22.100 

请注意，权限信息未显示。

是的，还有更多，但我又一次用完了分配的空间。在以后的专栏中，我想谈谈 NFS 的不同版本，如何更改甚至自动化远程目录访问，以及更多内容。所以，我在这里与您告别。下次再见之前，请记住您妈妈说过的话，“分享是美好的”。

正在查找本系列过去的文章？ 点击此处查看列表。