Re: Experiences with FreeBSD 9.0-BETA2

From: Benjamin Kaduk <kaduk_at_MIT.EDU>
Date: Mon, 26 Sep 2011 18:38:49 -0400 (EDT)
On Mon, 26 Sep 2011, Brett Glass wrote:

> 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.)

There was also general sentiment that the rise of ZFS would allow just 
this sort of fine-grained partitioning, which is a huge advantage of its 
ability to create datasets on the fly.  This perception that ZFS is most 
of the future probably contributed to the lack of strong opinions 
regarding the default UFS partition scheme.

-Ben Kaduk
Received on Mon Sep 26 2011 - 20:38:53 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC