wob*_*ene 4 sudo chmod symlink
最近我们在一个有很多用户的 Red Hat Linux 机器上遇到了一个问题：/usr/bin/sudo二进制文件丢失了它的粘性位。工作被阻止，直到 root 用户修复它（我们需要sudo部署和测试）。
这种故障的原因是...符号链接$HOME/bin/s指向/usr/bin/sudo. 我认为再多一个 bash 别名并不好，符号链接是一种更简单的解决方案，可以与任何 shell 一起使用，所以我创建了$HOME/bin/s指向.bashrc 的符号链接/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？有什么意义吗？
制作二进制文件的符号链接很好；检查/bin并且/usr/bin您几乎肯定会找到许多别名。这里的问题是在sudo没有完全理解后果的情况下使用。幸运的是，没有永久性伤害，您学到了重要的一课。当您只是确保它们是可执行的时，请使用a+x甚至u+x代替。正如uther 所说，无论如何，您最好使用别名。
手册页本身解释了为什么要执行此操作-符号链接的权限无关紧要，仅对它们解析的文件有影响。通常情况下，用户确实希望更改链接指向的文件的属性。
另外，我刚刚检查了chmod()Linux 和 BSD的syscall 手册页。它们都为符号链接循环返回错误，这意味着这种更改文件权限而不是链接权限的行为是在内核级别确定和强制执行的。