这似乎是一个显而易见的问题,但我没有得到任何真实的信息。在我的 Ubuntu 服务器中,我创建了一个自定义/etc/cron.d
配置文件,例如/etc/cron.d/MyCronTab
,我将所有内容放在这里的原因是为了易于查找并且易于修改。
现在我不会在这些 crontab 中添加任何敏感内容,但我发现默认情况下 Ubuntu 确实喜欢这些文件上的 644(root 可以读/写,每个人都可以读)。我想这可能是有意义的,这样人们就知道哪些任务将在后台运行,即使他们无法更改它们。
但就我而言,公开有关我的特定 crontab 文件的信息似乎不是一个好主意,因为无论如何它们都是 root 和管理任务。
所以我更改了我自己的文件()的权限,/etc/cron.d/MyCronTab
以便只有 root 可以读写,这看起来很完美,即使 crontab 有一个由另一个用户运行的任务,它仍然运行没有问题,这看起来很完美。
我担心的是,Ubuntu 或 cron 守护程序在更新时会将我的配置文件权限重置回 644,以便每个人都可以读取,还是永远保留在这个目录中?
答案1
这是你的文件,你控制它的权限——包更新和 cron 守护进程本身都不会改变它们。
一般来说,虽然下面的许多文件/etc
是由系统提供的,/etc
但它是系统管理员的域,系统将保留在那里所做的更改。即使对系统提供的配置文件所做的更改也会默认保留(如果升级过程中发生冲突,则会询问管理员如何处理)。
在 Debian 和良好的衍生版本(包括 Ubuntu)上,此要求在配置文件的策略部分;包可以将其配置文件处理委托给dpkg
,或在其维护者脚本中自行处理,这
必须是幂等的(即,如果
dpkg
由于安装或删除过程中的错误而需要重新运行它们,则必须正确工作),必须处理dpkg
可以调用维护者脚本的所有各种方式,不得在没有询问的情况下覆盖或以其他方式破坏用户的配置,不得提出不必要的问题(特别是在升级期间),并且必须是好公民。
即使在第一次安装时,现有的配置文件也会被保留;这意味着,如果在将来的某个时刻您最终安装的软件包与您自己的配置文件之一冲突,dpkg
则会询问您该如何处理。但是,清除包将删除其所有配置,包括您自己的被视为“属于”该包的文件;最好确保/etc
您的备份策略涵盖了这些内容,并且跟踪对 的更改也是一个好/etc
主意etckeeper
。