Quoting Didier Kryn ([email protected]): > Files are stored in different directories, that's it for > clean bookkeeping. Making these directories mountpoint does not add > any sort of ordering. Only the impression they are more secure.
Here's a real-world example of ordering using filesystem divisions. Let's assume a system using spinning rust -- a jocular term for hard drives, where 'seeking', the process of moving heads between cylinders, is by orders of magnitude the slowest read or write operation, as opposed to SSDs, where the concept of 'seeking' doesn't even apply, and all sectors are equally reachable in the same ultra-quick amount of time, with no seek delay ever. Ordering the file trees to minimise average seek distance and time will thus both speed disk access and reduce wear. Based on a lot of experimenting by me and others, and occasional but seldom systematic measurement, a _reasonable_ general scheme for each spindle is as follows: Near the middle of the set of cylinders, you put the spindle's swap partition. On _either_ side of the swap, you put a filessytem tree that has a high percentage of the system's reads and/or writes_. /var is one obvious candidate. Others might depend on the role of the machine, e.g., I tend to have a Web server's public HTML root mounted as /var/www (as I disagree with recent FHS releases about /srv for this), so it might go on the other side of the swap. And then, proceeding both inwards and outwards through the cylinders, other file trees with less and less average activity. If you have more than one spindle (unmirrored), then put likewise a swap partition in the middle, and festoon trees on either side following the same logic. About the 'impression that they are more secure', the problem with the word 'secure' in this context is that two speakers will often use it with entirely different referents in mind. For example, I might outline for you a partition scheme where /usr is ext2 and mounted read-only except during package operations and has the nodev mount option set, /var/lib is mounted nodev, /var/www is mounted nodev,nosuid, and /, /home /var/spool, and /usr/local have default mount options -- and your reaction was this gives only the _impression_ of being more secure, because a system intruder who cracks root can remount anything as desired to overcome such pitiful obstacles. But that assumes that 'secure' is intended to mean 'defeats remote intruders who steal shell and then successfully escalate to system privilege' -- whereas by 'secure' I might mean, in this context, something much more modest yet pragmatically useful: The biggest security threat to any *ix system is a tired and error-prone sysadmin working at a shell prompt. Anything that makes common blunders less disastrous without excessive cost is a win, e.g., /usr being normally mounted read-only averting disaster from an admin recklessly carries out a command with system authority that crosses into /usr without he/she intending to. Almost as threatening to systems is misbehaving regular software. Anything that makes processes going haywire less able to do harm without excessive cost is likewise A Good Thing. Last, although it's certainly true that a competent human intruder able to break in and escalate to root can trivially remount filesystems, most system attacks and privilege escalation are carried out by fully automated scripts, and, if they fail because they rely on writing to /usr, it's very likely they will _not_ be written to debug the problem as mount options and do a remount and try again. As usual, words are the problem. Maybe we should switch to interpretive dance. ;-> _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
