Mar*_*rio 9 permissions centos hard-link
当我尝试创建硬链接时，我在 CentOS 7 中遇到权限错误。在 CentOS 6 中设置相同的权限时，我没有收到错误消息。问题集中在组权限上。我不确定哪个操作系统版本是正确的，哪个是错误的。
让我来说明正在发生的事情。在我当前的工作目录中，我有两个目录：源和目标。一开始，destination 是空的；源包含一个文本文件。
[root@tc-dlx-nba cwd]# ls -l
total 0
drwxrwxrwx. 2 root root 6 Jun 12 14:33 destination
drwxrwxrwx. 2 root root 21 Jun 12 14:33 source
[root@tc-dlx-nba cwd]# ls -l destination/
total 0
[root@tc-dlx-nba cwd]# ls -l source/
total 4
-rw-r--r--. 1 root root 8 Jun 12 14:20 test.txt
[root@tc-dlx-nba cwd]#
如您所见，两个目录的权限为 777，所有者和组都设置为 root。文本文件的所有者和组也都设置为 root。但是，文本文件的权限对于所有者是可读写的，而对于组是只读的。
当我以 root 身份登录时，在目标目录中创建指向文本文件（在源目录中）的硬链接没有问题。
[root@tc-dlx-nba cwd]# ln source/test.txt destination/
[root@tc-dlx-nba cwd]# ls destination/
test.txt
但是，如果我以其他用户（在本例中为 admin）身份登录，则无法创建链接。我得到：“不允许操作。”
[root@tc-dlx-nba cwd]# rm -f destination/test.txt
[root@tc-dlx-nba cwd]# su admin
bash-4.2$ pwd
/root/cwd
bash-4.2$ ln source/test.txt destination/
ln: failed to create hard link ‘destination/test.txt’ => ‘source/test.txt’: Operation not permitted
发生的事情对我来说实际上是有道理的，但是由于 CentOS 6 允许上述内容，我想检查一下我是否误解了什么。对我来说，这似乎是 CentOS 6 中的一个错误，但已在 CentOS 7 中修复。
有谁知道是什么给的？我认为上述行为是正确的行为是否正确？CentOS 6 是正确的吗？或者，两者都是对的，也许我遗漏了一些微妙的组权限问题？谢谢。
编辑：我刚刚在我拥有的 Debian v7 VM 上尝试了相同的测试。Debian 同意 CentOS 7：“不允许操作”。
编辑 #2：我只是在 Mac OS X (Yosemite) 上尝试过同样的事情。这就像 CentOS 6 所做的那样。换句话说，它允许创建链接。（注意：在 OS X 上，根组称为“wheel”。据我所知，这是唯一的区别。）
我启动了一些新的 CentOS 6 和 7 虚拟机，并且能够重新创建您展示的确切行为。在进行了一些挖掘之后，事实证明，这实际上是内核中出于安全考虑而对硬链接和软链接的默认行为进行的更改。以下页面为我指明了正确的方向：
http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415
http://kernel.opensuse.org/cgit/kernel/commit/?id=800179c9b8a1
如果您使文件世界可写，您的管理员用户将能够创建硬链接。
为了恢复 CentOS 6 系统范围内的行为，添加了新的内核参数。在 /etc/sysctl.conf 中设置以下内容：
fs.protected_hardlinks = 0
fs.protected_symlinks = 0
然后运行
sysctl -p
至于为什么你的程序选择使用链接而不是复制文件，当你可以创建一个指向原始块的条目时，为什么要创建一个你需要使用的文件的精确副本？这样可以节省磁盘空间，并且操作在 CPU 和 I/O 方面的成本更低。新的硬链接是同一个文件，只是具有不同的元数据/inode。如果您在创建硬链接后删除原始文件，则不会影响该链接。只有在删除所有链接后，文件才会被“删除”。