I mostly agree with Brett regarding partitioning not being much of a 
security advantage (well, the point of UNIX-like partitions is that 
they're transparently mounted anyway, so it makes very little real-world 
difference).  However,

Brett Lymn wrote:

>I just see too many problems and very few advantages to slicing up a big
>disk into itty bitty parts.
>
>  
>
, which I don't agree with. The FreeBSD Handbook taught me valuable 
lessons on the advantages of partitioning. I can recap a few that stuck 
(and others that just make sense):

-You can move the Right Partition to the Right Place in the drive. swap 
should be towards the start of the disk, lesser-written partitions 
(home) should be towards the outer tracks. This seems like just rice 
rubbish on most drives, but I have a drive which can do 60+MBps (writes) 
on the start of the disk and barely ~30 on the outermost tracks (120GB 
Maxtor).

-Corruption of a partition doesn't affect other partitions. This isn't 
much of a problem with UFS because of superblock backups and clearly the 
most solid design possible (ReiserFS and so on *rely* on journalling, 
UFS is solid without it) but it's still best to have every possible 
measure against corruption. If you have your pkgsrc work dir in /var and 
a hard power drop happens during a build, chances are some nodes will be 
confused. fsck should fix this, but if it doesn't, at least your 
important (/usr, /, /home, etc) parts are secured. I once wiped a whole 
/var out on a BSD box and it worked fine on reboot, I just had to 
reinstall packages so as not to confuse the system. I can't say the same 
for /usr or / :)

-Re-installation with formatting (the expected way for significant 
restructures of a base system) can easily affect only the system parts 
and not /home. Backing up a large /home for a reinstall can be a severe 
pain, especially if you don't have an external hard drive.

-Read-only'ing partitions is more granular. I don't do this myself but 
there are times when it can be handy, like a dedicated firewall which 
should never, ever need changing but could be compromised or 
hard-dropped for whatever reason. Another good feature of read-only 
mounts is that they're impossible to corrupt from hard shutdown (see 
first point).

-More partitions allows you to specify partition-optimized mount/newfs 
flags. For instance, noatime for parts that don't need access times 
(well, just about everything except /var on a mail server, from what I 
hear), different block sizes, and so on. You can optimize /var for 
smaller files, /usr for larger ones, whatever you need. This does make a 
difference in storage and performance. Also, this CAN HELP in security, 
since noexec, nodev, and so on can be used for /var and /home to prevent 
users attempting local exploits (or remote exploits if you're running 
some really lousy server software). nodev should be used everywhere 
except / anyway.

-Different file systems (of course). Now that NetBSD has UFS and a solid 
LFS and both can be used for any partition without functioanl difference 
(that NFS slowness bug got fixed, right?), users can choose between the 
two. LFS could be useful for write-intensive partitions like /var to 
provide a boost in performance and reliability.



Now, this doesn't really help choose defaults. My strategy has been, for 
quite a long time, to have a very small / that's enough for the base 
package with some extra slack (this shouldn't get corrupted, since /tmp 
is ln'd to /var/tmp), follow this with swap space twice the size of RAM, 
a 4 gig /var, a 4-6 gig /usr (depends on how much software I expect to 
appear, and if the machine stores src and pkgsrc, which my gateway 
does), all else /home. At the very least, /home should be its own 
partition on a workstation or multi-user server (but not a dedicated 
gateway), even if only to make upgrades less frightening.