[conspire] Parititioning revisited briefly

[Rick Moen]

If you're bored from hearing about partitioning, you're out of luck,
because I had in mind to post tidbits about it until I run out of
inspiration.  Here's that server partition scheme, again:


# <file system> <mount point>   <type>  <options>       <dump>  <pass>

## sda is (obviously) the boot drive.  73 GB SCSI.
/dev/sda1       /boot           ext2    defaults        0       2
/dev/sda5       none            swap    sw              0       0
/dev/sda6       /var            ext2    noatime,nodev,nosuid 0       2
/dev/sda7       /               ext3    defaults,errors=remount-ro 0       1
/dev/sda8       /recovery       ext3    defaults        0       2
/dev/sda9       /usr            ext2    nodev,ro        0       2

## sdb and sdc are RAID1 mirrored, except for swap.  Each is 18 GB SCSI.
/dev/md0        /var/www        ext3    nodev,nosuid    0       2   #sdb5,sdc5
/dev/md1        /var/lib        ext3    nodev           0       2   #sdb6,sdc6
/dev/md2        /var/spool      ext3    defaults        0       2   #sdb7,sdc7
/dev/sdb8       none            swap    sw              0       0
/dev/sdc8       none            swap    sw              0       0
/dev/md3        /home           ext3    defaults        0       2   #sdb9,sbc9
/dev/md4        /usr/local      ext3    defaults        0       2   #sdb10,sdc10


This time, a few words about choice of filesystem type, mount flags and
such.  Let's start with /var.

First thing to note about /var is that I've carefully moved _off_ of the 
/var partition per se all the subtrees that contain indispensible
things:

/var/www   System HTML and ftp trees
/var/lib   all data files for Mailman, MySQL, some others
/var/spool System SMTP spools, NNTP spools, SpamAssassin files

Everything that remains is system-built dynamic files that come and go,
that you could blow away and would have minimal trouble from doing so.
_Therefore_, the first thing is that we want flat-out maximal
performance even at the expense of data protection, and there's nothing
better for that than good old ext2 (with no journal).  

You'll notice that /boot is likewise ext2.  I got into this habit during
the long period of reliance on the lilo bootloader.  One distinctive
thing about lilo is that the installed bootloader, at startup time, finds 
the system map, boot kernel, initial RAMdisk, and root filesystem first
sector by memorising their physical location (cylinder, head, sector,
etc.), _not_ by memorising their pathspecs within filesystems.
Therefore, lilo doesn't need to mount anything to do booting, and in
fact doesn't need to understand filesystems at all (to do booting).

Thus, when using lilo as one's bootloader, you actually almost never
need to mount /boot at all.  The only time you need to mount that
subtree is when _updating_ lilo data, e.g., because you just installed a
new kernel.

Leaving /boot normally unmounted is yet another small protection against
mishap.  Critical files in a subtree you haven't mounted are critical
files you cannot accidentally screw up.

And since you only ever mounted /boot a few times a year for fifteen
minutes at a time to implement new boot kernels, why waste space on a
filesystem journal?  Thus, ext2.

As mentioned, given the reduced rationale for having a separate /boot 
in the first place, I will be losing that filesystem in the future.


There are some restrictive flags on several filesystems, as a limited
sort of security measure:

/var      noatime,nodev,nosuid
/usr      nodev
/var/www  nodev,nosuid
/var/lib  nodev

The 'noatime' flag gives a filesystem a very non-trivial performance
gain, where you can get away with it, by eschewing the overhead of
continually updating the atime timestamp every time the file is 
accessed _including just for reads_.  ('File', here, includes 
directories.)  Some software relies on the atime timestamp, and 
disabling it (as above ) is consider a non-standards-compliant mode
of operation.  However, if no software requires atime for a subtree,
the gains are compelling.

(Note:  As of kernel version 2.6.30, Linux's default behaviour is 
something called 'relatime' = relative atime, invented by Valerie
Aurora, that greatly reduces atime overhead without software problems.
See:  http://valhenson.livejournal.com/36519.html )


/var's nodev and nosuid are very modest security measures of a sort.
That is, given that there's no conceivable legitimate purpose for
special device files (such as /dev/sda) within /var, why permit them to
be valid there?  Thus, nodev.  Given that there's no conceivable
legitimate purpose for SUID files within /var, why permit them to
be valid there?  Thus, nosuid.

A not-especially-sophisticated attack tool, say, a network worm, that
you or one of your users accidentally executed on your system, might be
foiled by an unexpected inability to have a special device file or a
SUID executable, functional within /var.  An astute human attacker with
root authority, or a sophisticated attack tool with root authority,
would easily defeat that safeguard by remounting /var without the flag,
so it's a modest measure.

The other three filesystems' similar flags are of the same sort.
Note that one must be careful not to shoot legitimate software in the
foot, in planning these flags.  Notice, for example, that /var/lib lacks
the 'nosuid' mount flag.  Doubtless, this is because I tried that and
noticed something that broke.  (Oops.)  But it's difficult to know until
you try.