Improving the reliability of file system monitoring tools (Collabora blog) [LWN.net]

Improving the reliability of file system monitoring tools (Collabora blog)

Posted Mar 15, 2022 23:15 UTC (Tue) by gerdesj (subscriber, #5446)
In reply to: Improving the reliability of file system monitoring tools (Collabora blog) by Wol
Parent article: Improving the reliability of file system monitoring tools (Collabora blog)

Wol, how much of root should be r/o? Just the top level? I think there are bigger fish to fry. For starters, having root go r/o is an early sign of damage on a fs - I've abused enough VMs to be familiar with this. Then you'll need a lot more mounts for all the other bits and pieces, including /root which really ought to be available no matter what (for root) so that there is a local place to store stuff in extremis.

I've never seen a distro do a r/o / either. It's just too much of a fiddle. Start down that path and you'll be doing things like maintaining a set of hard links with immutable flags set on them to stop the baddies instead of tripwire type solutions and other mad ideas. You can always play with SE Linux and co instead to get the desired effect too.

That's for desk/lap tops. Your servers/containers/etc are a different kettle of bits.

to post comments

Improving the reliability of file system monitoring tools (Collabora blog)

Posted Mar 16, 2022 8:27 UTC (Wed) by geert (subscriber, #98403) [Link]

I never made / read-only, but I did make /usr read-only, in the old days hard drives were small, and all of /, /usr, /var, /usr/local, /export/home1, /export/home2 (/home on autofs), ... were put on separate partitions. And after a while a bunch more, when you ran out of space.

Hence before and after doing "apt-get upgrade", I had to remount /usr read-write resp. read-only.

P.S. I'm not that old, as I'm mentioning /var ;-)

Improving the reliability of file system monitoring tools (Collabora blog)

Posted Mar 16, 2022 9:32 UTC (Wed) by ganneff (subscriber, #7069) [Link]

I actually had a server system (two, clustered with corosync/pacemaker) run with / fully ro. Only /home, subdirs (extra mountpoint) of /root and /var had been rw.
Login cluster for a server network. Back when even with grsecurity patches to lock down some more, including forbidden a remounting of things.

Worked pretty good, most of the time. Annoying to update (reboot into special rw-mode that didn't start services, update, reboot back to normal ro). Recently replaced with a new set of VMs and no more ro.

Sure nothing that one wants as standard, point is: It is actually *not* hard at all, to have it run so. And yes, it obviously depends on the exact usage of the system, as always.
(Server, not Desktop, that is).

Improving the reliability of file system monitoring tools (Collabora blog)

Posted Mar 17, 2022 10:00 UTC (Thu) by daniels (subscriber, #16193) [Link]

> I've never seen a distro do a r/o / either. It's just too much of a fiddle.

Apart from Fedora Silverblue, ChromeOS, SteamOS, etc.

> Start down that path and you'll be doing things like maintaining a set of hard links with immutable flags set on them to stop the baddies instead of tripwire type solutions and other mad ideas.

You're describing OSTree, used by Silverblue and SteamOS as well as many others.