我在 /tmp 目录中经历了奇怪的行为。尽管用户属于有权读/写文件的组，但他不能这样做。
在此示例中，我/tmp/test.txt以 user 身份创建一个新文件max。我给它777权限并使该文件属于该组root，但用户root仍然无法编辑它。
su max
touch /tmp/test.txt
chmod 777 /tmp/test.txt
su root
chown max:root /tmp/test.txt
# ls -l /tmp/test.txt
-rwxrwxrwx 1 max root 0 26. Feb 12:08 test.txt
# echo "foobar" > /tmp/test.txt
bash: /tmp/test.txt: Permission denied
当移动test.txt到不同的目录时，一切都会按预期进行。
/tmp是通过 fstab 通过以下选项安装的 tmpfs：
tmpfs /tmp tmpfs nodev,nosuid,size=5G 0 0
运行时ls -l /，tmp 文件夹如下所示：
drwxrwxrwt 20 root root 640 26. Feb 12:01 tmp/
我正在运行 Manjaro，Arch Linux 的衍生版本。
我挂载 tmpfs 时做错了什么吗？
答案1
您所显示的行为似乎取决于fs.protected_regularLinux 内核参数，该参数是fs.protected_fifos由这次提交（我相信是在 4.19 版本中聚合的），目的是修复安全漏洞。
提交消息摘录（强调我的）：
namei：允许 FIFO 和常规文件的受限 O_CREAT
不允许打开 FIFO 或世界可写粘性目录中不属于用户所有的常规文件，除非所有者与目录相同或文件在没有 O_CREAT 标志的情况下打开。目的是使数据欺骗攻击变得更加困难。 ...
同一条提交消息还报告了相关常见漏洞和暴露 (CVE) 编号的列表。
因此，如果userX被授予root或以其他方式被授予对 的写访问权限/tmp/file，并且这/tmp是一个设置了粘性位的世界可写目录，则它们只能file在以下情况下打开以进行写入：
userX是 的所有者file；或者file和目录都/tmp属于同一用户。
在您的测试中，root具有 的写入权限/tmp/test.txt，但不是该文件的所有者，也不具有/tmp/test.txt和/tmp相同的所有者（分别为max和root）。
该问题似乎与/tmp安装方式完全无关。
相关文档位于文档/sysctl/fs.txt:
受保护的先进先出：
此保护的目的是避免无意写入攻击者控制的 FIFO，其中程序预期创建常规文件。
...
受保护的_常规：
这种保护类似于 protected_fifos，但它避免写入攻击者控制的常规文件，而程序预计会在其中创建文件。
当设置为“0”时，写入常规文件不受限制。
当设置为“1”时，不允许 O_CREAT 在世界可写粘性目录中打开我们不拥有的常规文件，除非它们由目录所有者拥有。
当设置为“2”时，它也适用于组可写粘性目录。
也就是说，可以使用以下命令禁用上述保护：
sysctl fs.protected_regular=0
一些测试来支持我们的假设：
$ su - root
# sysctl fs.protected_regular
fs.protected_regular = 1
# cd /
# mkdir test
# chmod 1777 test
# su - otheruser
$ echo hello >/test/somefile
$ exit
logout
# cat /test/somefile
hello
# ls -lah test/somefile
-rw-r--r-- 1 otheruser otheruser 6 Feb 26 17:21 test/somefile
# echo root >>test/somefile
-bash: test/somefile: Permission denied
# sysctl fs.protected_regular=0
fs.protected_regular = 0
# echo root >>test/somefile
# cat /test/somefile
hello
root
# sysctl fs.protected_regular=1
fs.protected_regular = 1
# echo root >>test/somefile
-bash: test/somefile: Permission denied
# chmod 0777 /test/
# echo root >>test/somefile
# cat test/somefile
hello
root
root
fs.protected_hardlinks与和不同fs.protected_symlinks，默认情况下，内核代码中未启用 和fs.protected_regular。 启用它们是向后不兼容的更改（如您在fs.protected_fifos
这条评论指出），据我所知，systemd是在版本 241 中做到的，其中最近的这个提交。