Comment 0 for bug 493480

Binary package hint: upstart

Hi,

I've seen this discussed (with no solution) in several forums posts, and I've seen some "about similar" bug reports, but not the exact same, or marked "incomplete", so I file this one as I believe this is a high priority and security issue.

- After upgrade from Intrepid to Karmic, encrypted /tmp and encrypted swap defined in /etc/crypttab do not work any longer, where they worked perfectly before.

/etc/crypttab entries are i.e.:
c_swap /dev/mapper/VG1-c_swap /dev/urandom size=128,swap
c_tmp /dev/mapper/VG1-c_tmp /dev/urandom size=128,tmp

/etc/fstab entries are i.e.:
/dev/mapper/c_tmp /tmp ext2 relatime,nosuid 0 0
/dev/mapper/c_swap none swap sw 0 0

Symptoms are :
- During boot, cryptsetup always properly creates and formats the encrypted c_tmp and c_swap volumes with random keys - so that's no cryptsetup issue.

The rest of the system behaviour is not always consequent :
1/ The encrypted swap is sometimes properly "swapon'ed", and sometimes not.

2/ The encrypted /tmp is NEVER auto-mounted although it has been properly created and formatted

3/ The startup scripts always spit a message stating that "not all the partitions defined in fstab could be mounted"

4/ The boot process *sometimes* hangs with a "Type root password or CTRL-D to continue", and sometimes not.

5/ When the system finishes booting, typing "mount -a" gets the encrypted /tmp properly mounted.

(It's worth noticing that I also have an encrypted /home using a permanent key, and this one still works flawlessly...?!?)

It appears to me that the startup scripts are doing things asynchronously or in the wrong order for encrypted filesystems, and that's a major issue.

The system running with /tmp not mounted, thus potentially sensitive /tmp data stored unencrypted in the root filesystem, I mark this as a security issue.