2

It seems like an no brainer question, but i did not manage to any real information. In my Ubuntu server i have created a custom /etc/cron.d config file, e.g. /etc/cron.d/MyCronTab, the reason I put all here is for ease of finding and they are easy to modify.

Now I'm not going to put anything sensitive at all in these crontab, but i see by default Ubuntu really likes 644(root can read/write, everyone can read) on these files. I guess that could make sense so that people know what task will be running in the background even if they can't alter them.

But in my case, it seems rather not a good idea to even expose this information about my specific crontab files since they are root and admin tasks anyway.

So I changed the permission on my own files (/etc/cron.d/MyCronTab) so that only root can read and write, which seems perfect, and even if that crontab has a task ran by say another user, it still runs without issue, which seems perfect.

Something I'm worried about is, will Ubuntu or cron daemon on updates reset my config file permissions back to 644 so everyone can read or do they persist forever in this directory?

Improve this question

1 Answer 1

Reset to default
3

It’s your file, you control its permissions — neither package updates nor the cron daemon itself will change them.

As a general rule, while many files under /etc are provided by the system, /etc is the system administrator’s domain, and the system will preserve changes made there. Even changes made to system-provided configuration files are preserved by default (in case of conflict during upgrade, the administrator is asked how to handle it).

On Debian and well-behaved derivatives (including Ubuntu), this requirement is described in the Policy section on configuration files; packages can either delegate their configuration file handling to dpkg, or handle it themselves in their maintainer scripts, which

must be idempotent (i.e., must work correctly if dpkg needs to re-run them due to errors during installation or removal), must cope with all the variety of ways dpkg can call maintainer scripts, must not overwrite or otherwise mangle the user’s configuration without asking, must not ask unnecessary questions (particularly during upgrades), and must otherwise be good citizens.

Even on first installation, existing configuration files are preserved; this means that if at some future point you end up installing a package which conflicts with one of your own configuration files, dpkg will ask you what to do about it. However, purging a package will remove all its configuration, including your own files which are considered as “belonging” to the package; it’s best to ensure /etc is covered by your backup strategy, and it’s also a good idea to track changes to /etc with etckeeper.

Improve this answer
2
  • Is that guaranteed to be the case of all package files in /etc or only those listed in /var/lib/dpkg/info/package.conffiles? Commented Aug 21, 2023 at 19:00
  • For Debian and Ubuntu, the policy is stated here: debian.org/doc/debian-policy/ch-files.html#configuration-files and especially 10.7.3 which indicates that all configuration files (which are not always conffiles) must have user changes preserved on package upgrade. Although it does not directly state this, the generally accepted intention is that all files in /etc qualify as configuration files, and I believe that has been true for years at this point. Other distributions (like rpm based ones) will have different policies. Commented Aug 21, 2023 at 19:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.