Arch Linux

Nice patch :-)

Unfortunately things got a bit more complicated, because it turned out that there is a bug in the init script which causes the random seed to be restored after the encrypted partitions are set up.

This means that the patch will have to be modified after http://bugs.archlinux.org/task/17131 has been fixed.

The best idea I have on how to fix this right now is to manually set it up in rc.sysinit instead of using /etc/fstab, but I don't like that solution.

By the way, if you already have encrypted swap using /dev/urandom, there is an equally good (better?) way to have non-persistent, secure /tmp.

Mount a tmpfs filesystem on /tmp. For example, put in /etc/fstab:
tmpfs /tmp tmpfs mode=1777 0 0

It will be swapped out to your encrypted swap as RAM space is needed. In comparison, with an encrypted /tmp partition, Linux will buffer data and delay writing to disk, and Linux will cache data from disk when there is spare RAM or it was recently needed. This amounts to nearly the same thing (except I think with a physical partition, Linux is more aggressive about writing to disk -- which is useless in this case, because once your machine shuts down or crashes, you can't recover the randomly generated key anyway).

If you want tmpfs to be limited to a particular megabyte/gigabyte size, use the size= mount parameter (the default is half the size of physical RAM) -- see `man mount`.

by the way, this is mentioned in less detail on the wiki at http://wiki.archlinux.org/index.php/Maximizing_performance#Mounting_.2Ftmp_to_RAM

And if you have swap that is unencrypted, then there's little point encrypting /tmp. If there's anything useful in /tmp, an application is likely to read() it sometime. And then this bit of RAM the application is using might be swapped out.

If you have no swap at all (horrors!), then I can see encrypted /tmp having a place...

Also, in http://bugs.archlinux.org/task/11648 , Oct. 2009, Thomas Bächler (brain0) says that he's redesigning crypto initscripts to have more flexibility than the crypttab syntax. Should we wait and see?

oh, Thomas says recently, that's one of the things he hasn't found time to do. http://mailman.archlinux.org/pipermail/arch-dev-public/2010-March/015869.html

(slightly off-topic) I thought of the task of generalizing crypto support. For myself, currently I don't use crypttab, just a script I run manually and enter my password; and there is about one other setup I think of wanting personally. For a sane generalization (whole distro's crypto scripts), I'd need to gather as many users' desired use cases as possible first, and then try and fit them. (mailinglist, plus something can be gleaned from the set of crypto initscrip bug-reports...)

I think in light of Isaac's suggestion, there is really no need for this feature, so I'm closing this as won't implement.
If anyone is interested in helping out with the crypto support, please take it to the <arch-projects@archlinux.org> mailinglist. I would suggest having a look at how this is done in systemd, afaik they base what they do on what is done in debian. I think it would make a lot of sense to try to coordinate this effort with other distros.