linux - 在 Linux 上创建硬链接(hard link)期间的 EACCES 不匹配 link(2) 手册页中的任何原因

Question

我有一项服务，该服务将指向一组文件的硬链接(hard link)组装到一个临时暂存目录中，这些文件具有读取权限但没有写入权限(以及所有父目录树的遍历权限)。

这非常有效，直到我的 AWS 托管节点重新启动。看起来他们现在在更新的内核上，并且 link(2) 调用现在返回 EACCES。

检查此系统调用的 (Linux) 手册页:

EACCES - Write access to the directory containing newpath is denied, or search permission is denied for one of the directories in the path prefix of oldpath or new‐path. (See also path_resolution(7).)

为了比较，BSD 版本似乎描述了相似的语义，也许更详细一些:

[EACCES] A component of either path prefix denies search permission.

[EACCES] The requested link requires writing in a directory with a mode that denies write permission.

[EACCES] The current process cannot access the existing file.

这些情况都不适用:作为运行该服务的用户，我可以读取源文件(包括遍历其目录)，并写入临时暂存目录(实际上是我创建的)；此外，该暂存目录位于同一文件系统上(尽管这会导致不同的错误)。

什么给了？

Answer 1

重新启动时，新内核默认启动到 set fs.protected_hardlinks=1。 This was added as default behavior in late 2012.设置此 sysctl 后，Linux 需要在允许其他用户创建指向该文件的硬链接(hard link)之前对文件进行写访问。

这在技术上与 the relevant POSIX specification 兼容，其中部分说明:

The implementation may require that the calling process has permission to access the existing file.

---

然而，newer upstream kernels have this off by default, due to its observed ability to break third-party software .因此，在当前情况下，它要么由供应商重新启用，要么基于从引入到后来禁用之间的时间段的上游内核。