←back to thread

When root meets immutable: OpenBSD chflags vs. log tampering

(rsadowski.de)
134 points todsacerdoti | 4 comments | 18 Jul 25 08:36 UTC | HN request time: 1.519s | source
Show context
johnisgood ◴[18 Jul 25 08:59 UTC] No.44602632[source]▶
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.
replies(3): >>44602842 #>>44603152 #>>44604893 #
knorker[dead post] ◴[18 Jul 25 09:45 UTC] No.44602842[source]▶
[flagged]
johnisgood ◴[18 Jul 25 09:49 UTC] No.44602873[source]▶
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.
replies(1): >>44604284 #
JdeBP ◴[18 Jul 25 13:10 UTC] No.44604284[source]▶
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.

replies(2): >>44604643 #>>44604955 #
1. johnisgood ◴[18 Jul 25 13:51 UTC] No.44604643[source]▶
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.
replies(1): >>44604896 #
2. JdeBP ◴[18 Jul 25 14:17 UTC] No.44604896[source]▶
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. (-:
replies(2): >>44605174 #>>44605656 #
3. throw0101c ◴[18 Jul 25 14:41 UTC] No.44605174[source]▶
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.

4. johnisgood ◴[18 Jul 25 15:18 UTC] No.44605656[source]▶
I think the reason was resolveconf and package updates, yes.