Quoting Didier Kryn (k...@in2p3.fr): > I don't see any reason to encrypt /usr. You might like to > encrypt /etc because it contains user names and (already encrypted) > passwords. But definitely there is no reason to encrypt everything.
/home would be where I keep anything that's sensitive. I'm unclear on why usernames in /etc are deemed sensitive, but I'm sure needs differ. Temporary files in /tmp are sometimes a little sensitive and sometimes greatly so. (It's usually a tmpfs on my systems.) Operational paranoia suggests keeping it at least cleaned up frequently, if you're going to bother to have /home as a dmcrypt filesystem. That's where tmpfs is actually helpful in the sense that erasure means a file from there is truly gone. Stephan's assertion that dmcrypt rootfs is impossible without an initrd certainly _might_ be correct. In casual reading, I found that one obstacle is that the code for the 'cryptdevice' and 'cryptkey' keywords in GRUB work only with initrd. There are similar keywords for syslinux, but I couldn't tell in a quick survey whether they are initrd-specific. Anyway, my broader point is that, if I wanted to mount my rootfs as dmcrypt, I'd try a few things and see if it could be done my preferred simplified-architecture way with a locally compiled kernel without an initrd. Are there further obstacles beyond bootloader keyword limitations? That's what trying would determine. If nothing seemed to work, I'd probably just punt and build a minimal initrd just for the things seemingly inaccessible any other way. (There's no point in being a fanatic about it.) Since I don't happen to want to try that today, that's an exploration for another time (in my view). And my even broader point is that nowhere is it written that a technology must be absolutely universally loved by, and useful to, everyone before anyone is allowed to like and use it. Calling how I've maintained my computing home on Linux a 'niche' since 1993 seems like a little much. Your niche, my normality. This isn't Microsoft; one size isn't required to fit all. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
