[ On Monday, June 9, 2003 at 01:51:21 (-0400), Chuck Yerkes wrote: ]
> Subject: monolithic roots (Re: Rototil of sysinst partitioning code)
>
> No, they won't.  If / gets whacked, and /usr is readonly, then a 60MB
> fsck takes far less time than a multi gigabyte fsck.

Bzzzt #1.  /usr, when it is a separate filesystem, isn't read-only by
default, and currently cannot be made so with the default install
tools.  I.e. you're talking about a customized system, not the default
configuration.

Bzzzt #2.  The base OS components that reside under /usr do not account
for multiple gigabytes of additional storage requirements -- only a few
hundred megabytes which will fsck in less than the blink of an eye on
any modern system where you'd be worried about fsck time in the first
place.  Even if you've got X11 and /usr/pkg with several thousand
packages or so installed then you're still only up to a couple of
gigabytes of very static data.  If you're worried about fsck time then
you'll be equally, or even more, worried about run-time speed of your
system disk and you'll have made it fast enough that the fsck will still
be only a tiny bit longer compared to the overall in-convenience of any
crash you might suffer.

Speaking of the in-convenience of crashes, if you were doing a proper
cost/benefit analysis of your vulnerabilities and their mitigation then
you'd spend a wee bit more on making your hardware and power and such
more reliable so that you didn't suffer crashes in the first place.

> Oh, and /usr won't corrupt on readonly file systems - there are no
> outstanding buffers.

No quiescent filesystem will be corrupted (significantly -- i.e. beyond
what an auto-fsck can fix) by any crash.  A root filesystem that
includes the base OS /usr components, and even one that includes
/usr/pkg, is no more likely to be any less quiescent and thus no more
corrupted by a crash.  I.e. putting the base OS /usr components on the
root filesystem does not cause it to be written to by any process nor
does it allow it to be written to by any unprivileged user.  The
increase of risk to the root filesystem by the presense of the base OS
/usr components is infinitesimal -- much smaller than even one of the
many other more significant vulnerabilities that will require off-site
backups to get anywhere near the level of reliability and recoverability
you were blathering on about.

Those with the necessary skills can waste their time and energy doing
all kinds of crazy things to make believe they've made a more reliable
and/or more easliy recoverable system, but we're talking here only about
the out-of-the-box defaults, not about what a few overly paranoid folks
do.  Those who don't do careful scientific risk assessments are often
doomed to waste their time and energy on pointless customisations.

Out-of-the box there is no measurable increased risk for most real world
scenarios caused by putting the base OS /usr components on the root
filesystem.  While it may be true that the out-of-the box configuration
is too risky for some scenarios and some overly paranoid types, none of
that risk is caused by putting the base OS /usr components on the root
filesystem since much of that risk is there for the root filesystem
regardless of where the base OS /usr components reside.

If you're really paranoid about your system then you'll run it in
production with the root filesystem mounted read-only too, in which case
all the noise about keeping /usr as a separate filesystem goes right
out the window in the puff of invisble, tasteless, odourless, smoke that
it started out as.  After all if you're that paranoid about your
system's integrity then cost and inconvenice are no objection, right?

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>