At 12:03 PM 9/26/2011, Benjamin Kaduk wrote: >On Mon, 26 Sep 2011, John Baldwin wrote: > >>I can't speak to the "one-big-fs" bit (there was another thread >>long ago about >>that). However, as to the partitioning bit, bsdinstall is >>defaulting to using > >The question of how to layout and split filesystems was discussed >at the filesystems working group of the devsummit at BSDCan this >may. (http://wiki.freebsd.org/201105DevSummit/FileSystems down to >"Filesystem Layout" near the bottom) Though "one big root" did >not garner a huge amount of support, neither were there >particularly compelling arguments against it (if I remember >correctly). It's certainly easier to write an autopartitioner >for, so I don't really blame Nathan for having chosen it initially. My personal preference would be to place portions of the directory tree which contain critical configuration information and are not written in normal use -- e.g. /etc and /boot -- in one or more separate partitions. This would make it possible to mount them read-only unless the system configuration was being changed, new software was being installed, or a new kernel was being generated. This would protect them not only from malicious tampering but also from being scrambled by buggy userland software. And since it would not be written during normal operation, it would survive 100% intact even if journaling and/or serialization of metadata updates (e.g. softupdates) were to fail. Unfortunately, due to past history, /usr is mixed-use. It normally contains both configuration information -- e.g. /usr/local/etc -- and more volatile data such as users' home directories. This prevents /usr/local/etc, which also contains mission-critical configuration information, from being protected if you just protect /. Some proprietary Unices have fixed this historical flaw in the traditional hierarchy by moving /usr/local/etc to another location and them symlinking it back to where seasoned administrators expect it to be, thus honoring POLA. The three open source, old school BSDs (Free, Net, Open) have not done this to date, but it's something that should be considered in the long run. It would certainly make the creation of embedded systems easier, as well as enhancing security in multi-user systems! If I wrote an installer, my preference would be to have it create one partition that contained critical configuration information and software (and could be mounted read-only) and one that contained the rest of the usual directory tree (and could be mounted read-write). It could do the symlinking trick mentioned above to bring parts of /usr over to the read-only administrative partition. The only cleanup task that would remain would be to make sure that no ports were configured to place their logs, pid files, etc. in directories such as /usr/local/etc. (Most already do not.) --BrettReceived on Mon Sep 26 2011 - 19:14:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC