☰

为什么 /etc/crontab 在环境中设置 HOME=/ ？

tag-icon • tag-icon cron rpm
为什么 /etc/crontab 在环境中设置 HOME=/ ？

我发现/etc/crontab许多基于 RedHat (EL/Fedora) 的发行版中的系统 crontab 包含以下行：

首页=/

此配置似乎也显示在互联网上的许多文档/示例中，并且在显然被删除之前，这种方式显然已经存在很多年了2010 年 RPM 版本 1.10-34。也许类似的配置存在于 Debian/其他基于安装的安装中，如果读者对具有相同配置的发行版有明确的了解，请添加评论，我将在此处扩展文本。

我在这里问的问题是：
在系统 crontab 中将 HOME 设置为文件系统根目录有哪些好的技术原因？我只对技术理论感兴趣，或者最好是历史原因，为什么这个配置在某些发行版中存在了这么多年，而不是意见。我只是想知道在标准的旧发行版中删除此配置可能会导致什么问题 - 大概这些原因在已删除的上游版本中不再存在，或者删除的人可能不知道潜在的问题这修复了。

我最近通过HOME=/在 EL6 系统上删除这个解决了一个问题，我的研究表明这个配置多年来一直是许多系统的标准配置。在我看来，这可能会导致比它解决的问题更多的问题，所以我开始对任何它可以帮助解决的情况感兴趣，我可以通过删除它来开放自己。

作为背景，问题是 cron 触发的mysqladmin命令似乎开始忽略它~/.my.cny- 似乎开始使用不同的 MySQL 安装或更新，$HOME/.my.cnf而不是.my.cnf在主目录中使用/etc/passwd.我添加此内容是为了防止其他人遇到类似的问题，并且也许可以使用此信息找到更快的解决方案。

答案1

守护进程通常执行一个chdir("/")或等效的操作，因此它们不会在某些（可能是远程安装的）目录中启动，从而不必要地使所述目录的卸载或重新安装变得复杂。 cron 作业的HOME=/可能会模仿这一点，因此随机（可能是长时间运行的）作业不会不必要地位于急需卸载或重新安装的目录中。 （当然，如果~/.my.cnf需要并且位于远程安装目录上，那么这是一个不必要的脆弱性什么时候网络或远程系统出现故障，该 cron 作业将会不高兴。）

在 OpenBSD 上，rootcrontab 文件实际上将事情设置为

HOME=/var/log

默认情况下。如果您想测试主目录是什么，因为您不确定设置来自哪里，或者编写一个 cron 作业来告诉您这一点（并确保在 cron 垃圾邮件之前将其删除）：

* * * * * /bin/pwd

还！完全限定配置文件的路径可以帮助避免由于环境设置泄漏到本地目录中的本地文件或从本地目录中的本地文件泄漏而选择错误的配置文件。

（从历史记录来看，文件曾经root存在于某些类型的 UNIX 中，/而不/root存在于任何地方，甚至所有内容都可以从其他地方安装；当时磁盘要昂贵得多......）

相关内容