which doesn't cover someone adding in  /usr/lib/libc.so.blah.N
(where N > current).

And it doesn't cover where fsck isn't needed, ever, on that
large filesystem.

I'm still trying to figure out the benefits?  Working around
poor planning?  If your /usr is going to double in size, then
something else is going on.

Working around a very dynamic machine that might be getting
new builds every week?  That's a different role and quite
valid.


Quoting Greg A. Woods (woods@weird.com):
> On Monday, 16 December 2002 at 14:43:36 -0800, Chuck Yerkes wrote:
> >
> > I'm a very strong advocate of making /usr separate because I
> > mount it read-only.  In fact, except for root, if it's got
> > a binary on it, it's RO.  If it's got data, it's mounted
> > noexec, nosuid, nodev.  Several reasons.  And I've built machines
> > where the binaries are on disks PINNED read-only (trojan that!).
> 
> It's far easier to get much better read-only coverage of your sensitive
> files using the immutable flag -- then you can protect scripts and
> binaries and static data files on the root FS too.
> 
> -- 
> 								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>