☰

符号链接的 chmod 行为是否错误？

tag-icon • tag-icon sudo symlink chmod
符号链接的 chmod 行为是否错误？

最近，我们在一个有很多用户的 Red Hat Linux 机器上遇到了一个问题：/usr/bin/sudo二进制文件失去了粘性位。工作被阻止，直到 root 用户修复它（我们需要sudo部署和测试）。

此故障的原因是...$HOME/bin/s指向 的符号链接/usr/bin/sudo。我认为多一个 bash 别名不好，符号链接是一种更简单的解决方案，可以与任何 shell 一起使用，所以我创建了$HOME/bin/s指向/usr/bin/sudo.然后一个人将我的复制$HOME/bin到他的$HOME并“以防万一”打电话sudo chmod 755 $HOME/bin/*。结果/usr/bin/sudo得到了 0755 权限，而不是所需的 4111。现在它已修复，root 已登录并恢复了 sudo 的权限。

man chmod（红帽、Ubuntu）：

  chmod never changes the permissions of symbolic links; the chmod system
  call  cannot change their permissions.  This is not a problem since the
  permissions of symbolic links are never used.  However, for  each  sym-
  bolic link listed on the command line, chmod changes the permissions of
  the pointed-to file.

我的问题是：这是我的错吗，因为我不应该创建指向二进制文件的符号链接，或者行为chmod错误并且它不应该更改符号链接指向的文件的权限？为什么会有这样的行为chmod？这有什么意义吗？

答案1

为二进制文件建立符号链接是可以的；检查/bin一下/usr/bin，你几乎肯定会发现许多别名。这里的问题是sudo在没有完全理解后果的情况下使用。幸运的是，没有造成永久性伤害，您学到了重要的教训。当您只是确保它们可执行时，请使用a+x或 甚至u+x代替。作为乌瑟尔 说，无论如何，使用别名可能会更好。

手册页本身解释了为什么要执行此操作 - 符号链接的权限并不重要，重要的是它们解析到的文件的权限。通常，用户确实想要更改链接指向的文件的属性。

另外，我刚刚检查了chmod()Linux 和 BSD 的系统调用手册页。它们都返回符号链接循环的错误，这意味着更改文件权限而不是链接权限的行为是在内核级别确定和强制执行的。

答案2

我同意，如果您将符号链接视为符号链接，那么它没有多大意义。

但如果您将符号链接视为硬链接，那就更有意义了。

第一行man 7 symlink正是这样说的

Symbolic links are files that act as pointers to other files. 
To understand their behavior, you must first understand how hard links work.

A hard link to a file is indistinguishable from the original file because
it is a reference to the object underlying the original filename.
[...]
Changes to a file are independent of the name used to reference the file.

因此，通过硬链接，当您通过任何名称更改文件的权限时，所有名称的基础权限都会更改。

大多数工具都会尝试遵循符号链接，以便您可以假装它确实是硬链接。

Except as noted below, commands follow symbolic links named as
command-line arguments.

The mv(1) and rm(1) commands do not follow symbolic links named as
arguments, but respectively attempt to rename and delete them. 

Commands traversing a file tree [...]

创建二进制文件的符号链接（或硬链接）有时很有用，但正如您刚刚发现的那样，它确实会产生一些可能导致问题的极端情况。

也就是说，我认为这里更大的问题是sudo在不需要的时候使用它。

如果其他用户应该具有对您的的读取权限~/bin，那么sudo完全没有必要。

或者，如果他们没有访问权限，您可以授予它（例如使用chmod g+rx $HOME/bin），或者为他们提供 tarball。

如果您仍然认为使用sudo是一个好主意，这里有一些替代方案：

sudo chown -h $USER $HOME/bin/*
chmod 755 $HOME/bin/*

-h告诉chown不要遵循符号链接

chmod -R 755 $HOME/bin/*

-R告诉 chmod “遍历文件树”，这使得它忽略符号链接，如上面在man 7 symlink.

sudo find $HOME/bin/ -type f -exec chmod 755 {} +

-type f告诉find不要chmod在符号链接上运行 exec 命令（在本例中）。

# as user 2
cd ~user2/bin
sudo tar -C ~user1/bin -cf - . | tar -xf -

以 root 身份运行tar -cf，以便您可以查看任何文件，但tar -xf以 user2 身份运行，这会导致提取的文件归 user2 所有。

答案3

米克尔已经说过了，但它有点埋藏在他的答案中，所以：真正做错的是

sudo chmod 755 $HOME/bin/*     # <<<< highly suspicious!

需要超级用户权限才能对主目录中的文件进行操作，这是相当奇怪的。如果那家伙发现他没有权限在自己的主目录中执行某些操作，他应该调查一下情况，而不是盲目地运行 sudo。重申一下：不要盲目运行sudo。如果那家伙跑了chmod 755 $HOME/bin/*，那么他会看到错误消息chmod: changing permissions of/home/guy/bin/s': 不允许操作`。

顺便说一句，我不建议为（如果您必须这样做，我建议您使用 shell 别名而不是符号链接：此名称对脚本可用是没有意义的）创建s别名。这不是良性操作，您可以在运行时输入三个额外的字符。给它一个单字符别名会增加拼写错误的风险。sudosudo

有点令人惊讶的是，chmod当大多数元数据操作作用于链接本身时，作用于符号链接的目标。然而，符号链接没有有用的权限：它们永远不会被写入（仅创建和覆盖）或执行，并且几乎没有任何隐藏其目标的意义。 Unix 变体在是否chmod影响符号链接（并非所有系统都支持）、其目标或两者都不影响方面有所不同。在 Linux 上，chmod影响目标。

答案4

创建别名和创建到文件的符号链接都是有效的（尽管通常首选别名）。我不认为这种情况有什么“错误”。这是 的行为chmod，因此现在您知道如何chmod在符号链接文件上工作（它没有改变）并且可以避免将来这样做。如果它再次发生，您知道如何解决它。

相关内容