“私有 /tmp 就像一个好主意......它对我有用，它更安全，所以让我们重新分发给世界上自 1970 年以来期望 /tmp 是 /tmp 的每个 UNIX 人......”得到？爆炸、破坏和你的身体着火。
我试图在 Debian 9 上禁用 private /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跑了，一切都因为私人tmp而被打破；然后我需要再次重新禁用它。我们使用一个 Web 系统，该系统与在控制台上运行的另一个旧系统进行通信……它通过 tmp 进行通信。
我做错了什么？我应该重新启动服务器吗？
答案1
它缺少systemctl daemon-reload重新加载 systemd 单元文件的步骤。首先执行此操作，然后重新启动服务
重新启动整个服务器也可以，但这不是必需的。
PS如果您遇到与链接文章相同的问题，apache想要读取由cronjob编写的一些文件，您可以通过不使用/tmp来处理这些文件以更细粒度的方式解决这个问题。您也许能够配置一个可由 cronjob 写入的目录，而不必担心使用 /tmp 带来的安全问题。即，在您所需的进程可以保留它之前，另一个 UID 可能能够窃取 /tmp 中的硬编码套接字名称/子目录。