[conspire] Parititioning revisited briefly
jim at well.com
Fri Oct 15 19:36:02 PDT 2010
I love it, thanks lots! More, more....
On Fri, 2010-10-15 at 18:33 -0700, Rick Moen wrote:
> 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
> /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.
> conspire mailing list
> conspire at linuxmafia.com
More information about the conspire