When root meets immutable: OpenBSD chflags vs. log tampering

It is not the same, but I do use "chattr +i" on a file (which applies the immutable attribute) on Linux to a file that otherwise would have been overwritten by programs that do not give a damn whether I want it to or not, and in my case it was easier to just make that file immutable, mainly: /etc/resolv.conf.

That actually does not sound too far-fetched. I believe there is a high chance that it might eventually happen, at least to files systemd """cares""" about.

.bash_history

Better yet, `shopt -s 'histappend'` in your .bashrc and `chattr +a .bash_history`. This will still allow bash to add to the history, but it won't be able to trim the file.

I am curious, what files do you use it on specifically?

In reality, this is something that people have been doing to systemd-resolved in desperation since the late 2010s (e.g. https://unix.stackexchange.com/q/421977/5132 for one of many examples), and systemd has not been changed in all of that time to undo this.

It is actually an unnecessary act of desperation, as systemd does have a way of setting things up so that /etc/resolv.conf is entirely manually configured. It's just (a) not completely obvious to deduce from the systemd doco, and (b) something that gets the blame for things that actually lie elsewhere in the system that also need disconnection, like /etc/nsswitch.conf giving nss-resolve priority over nss-dns.

That that situation remains the case today (five years after I wrote https://unix.stackexchange.com/a/612434/5132 for example, and almost a decade since the desperate making resolv.conf immutable idea took off) is a good indicator that the systemd developers aren't in reality in any hurry to force some hypothetical total ownership of /etc/resolv.conf by systemd.

The system on which I am using "chattr +i" is not even a systemd one. I forgot why I set the attribute in the first place. I might be able to figure it out, but it was the simplest and least time-consuming yet effective solution at the time. I think there were more than one reasons for it.

Are you using systemd-resolved? If so, it's actually a symlink to /run/systemd/resolve/stub-resolv.conf, and all you need to do to manage it yourself is to turn it into a regular file of your own. This is explained in the admittedly very long commented out text above the actual directives.

My educated guess would be either NetworkManager or resolveconf (or a DHCP client not even going through resolvconf), with fun with package upgrades resetting customizations as my second choice educated guess. (-:

Yes! And for macOS, `chflags uappnd .bash_history`

I find it baffling that distributions are making all of these system-level changes away from how a 'traditional' Linux/Unix does/did things, towards handling 'dynamic' situations, when a large portion of the installed of Linux is probably servers: i.e., why would you even consider the DHCP client situation for a server?

As a sysadmin I want a static files that never change, and whose mtime is from when I installed the thing two years ago. I'll either launch vi to make changes or Ansible/Puppet/etc.

Make the default the default as static-y as possible, and if someone is installing a personal system have a "laptop-config" or "desktop-config" package that adds all the dynamic bits separately.

I think the reason was resolveconf and package updates, yes.

No, it is a runit-based system. I think the issue was related to resolvconf + package updates overwriting the file.

That said, I am sure your comment will be useful to some!