根压缩意味着当我尝试访问已启用它的目录时，我将无法使用我的根权限，因为它将被重新映射到 nfsnobody 用户或指定的任何用户。我想知道以下情况；如果我以 root 身份在自己的计算机上创建一个可执行文件，并设置 ( chmod u+sx) executable.sh 的 UID，然后将该文件复制到 NFS 服务器，我仍然无法以 root 身份执行，因为它将被重新映射到 nfsnobody 用户。尽管如此，想象一下我能够以具有平均权限的普通用户身份（没有 root 或其他任何权限）通过 SSH 连接到同一台服务器。如果我在那里执行相同的 executable.sh 文件，它不会被重新映射，对吗？我认为它将以 root 用户身份执行。
我的假设正确吗？如果不正确，那么一些澄清将会非常有用！
还有一个小问题：使用 SMB 时是否存在类似 root 压缩的功能，因为我只需将文件从我自己的计算机复制到设置了 UID 的 smb 共享（该文件由 root 创建）chmod u+sx并在那里执行它即可？
祝你有美好的一天！
答案1
如果我以 root 身份在自己的计算机上创建一个可执行文件，并设置 (chmod u+sx) executable.sh 的 UID，然后将该文件复制到 NFS 服务器，我仍然无法以 root 身份执行，因为它将被重新映射到 nfsnobody 用户。
听起来你假设“root_squash”适用于服务器报告的信息，但不适用于客户端身份。但事实恰恰相反：“root_squash”适用仅有的用户凭证（即谁在执行操作），而不是文件所有权。
换句话说，这意味着你不能声称是在对 NFS 共享文件进行操作时，可以使用 root 权限（因此无法进行 chown 等），但这并不能阻止现存的文件看起来好像由 root 拥有。
这意味着启用“root_squash”将更早地停止你的计划：它将阻止你复制该文件到 NFS 服务器。如果您以本地 root 身份执行复制操作，则复制的文件将显示为“nfsnobody”所拥有，因为 NFS 服务器将忽略您的“I am uid 0”声明。如果您尝试将其“chown”回 root:root，NFS 服务器将不允许您这样做，因为只有 root 可以 chown 文件，并且您的连接仅具有“nfsnobody”权限。
另一方面，“root_squash”将不是阻止本地计算机执行实际上由 root 拥有的文件。这种情况是相反的：当您在 NFS 共享中运行程序时，它仍然在您的客户端计算机上被读取和执行 - 而不是在服务器上 - 因此与前一种情况不同，现在是 NFS客户它相信服务器提供的有关文件所有权或权限的信息，而“root_squash”不会改变这些信息。
（因此，如果 /mnt/theserver/bin/su 已经存在，并且 NFS 服务器表示它是 setuid-root，则您的 NFS 客户端计算机将像执行 setuid-root 一样执行它，而不管 root_squash 如何。为了避免这种情况，NFS 客户端需要使用“nosuid”选项挂载共享。）
尽管如此，想象一下，我能够以普通用户的身份通过 SSH 连接到同一台服务器，普通用户拥有一般权限，没有 root 或其他权限。如果我在那里执行相同的 executable.sh 文件，它不会被重新映射，对吗？我认为它将以 root 用户身份执行。
如果你真的能够创建这样的可执行文件，那么是的（但请记住 Ninov 在评论中所说的：setuid 仅适用于二进制可执行文件，并且对于脚本完全被忽略）。
但是您无法达到这个阶段，因为“root_squash”首先会阻止您创建 root 拥有的文件。
还有一个小问题：使用 SMB 时是否存在类似 root 压缩的功能，因为我只需将文件从我自己的计算机复制到 smb 共享（该文件由 root 创建）并设置 UID（chmod u+sx）并在那里执行它？
root_squash 无关紧要，因为 SMB 本身就没有基于 UID 的身份验证。SMB 连接纯粹是面向帐户的（即客户端必须提供明确的凭据，而不能只是声称自己是“UID 123”），因此不存在可能或需要被压制的隐式 root 访问权限。
因此，要么使用单个帐户为每个人安装 SMB 共享（使其好像全部远程帐户被压缩为本地用户），或者共享以多用户模式挂载，其中每个本地用户都必须提供自己的凭据。
但正如开头提到的那样，“root_squash”不会影响文件的外观；如果某个文件已经由 root 拥有，它仍然会看起来像是由 root 拥有的。它是“ nosuid”选项，可防止客户端意外执行 setuid 二进制文件，并且它是一个全局 VFS 层选项，可与 SMB 挂载以及任何其他文件系统类型配合使用。