Debian 上的 Systemd private /tmp，无法以正确的方式禁用它

Question

“私有 /tmp 就像一个好主意......它对我有用，更安全，所以让我们重新分发给世界上每一个自 1970 年以来希望 /tmp 是 /tmp 的 unix 人......”你做什么得到？爆炸、破坏和你的身体着火。

我试图在 Debian 9 上禁用私有 /tmp，所以我按照这个站点的说明操作：

https://www.maxoberberger.net/blog/2017/10/debian-9-private-tmp.html

这看起来很不错，但事实并非如此，它引起了一些心痛。

当我尝试通过在 上创建覆盖文件来禁用时/etc/systemd/system/apache2.service，systemd 似乎完全忽略了我。

我需要直接编辑文件：

/lib/systemd/system/apache2.service

这是可行的，但如果您升级系统，这并不是一个好主意！今天unattended-upgrade跑了，因为private tmp什么都坏了；然后我需要再次重新禁用它。我们使用一个 Web 系统与另一个在控制台上运行的旧系统进行通信……它通过 tmp 进行通信。

我做错了什么？我应该重新启动服务器吗？

Answer 1

它缺少systemctl daemon-reload重新加载 systemd 单元文件的步骤。首先执行此操作，然后重新启动服务

重新启动整个服务器也可以，但这不是必需的。

PS，如果您遇到与链接文章相同的问题，并且 apache 想要读取由 cronjob 编写的某些文件，您可以通过以下方式以更细粒度的方式解决此问题……不对这些文件使用 /tmp。您也许可以配置一个可由 cronjob 写入的目录，而不必担心使用 /tmp 会带来安全问题。即在您想要的进程可以保留它之前，另一个 UID 可能能够窃取您在 /tmp 中的硬编码套接字名称/子目录。