[Bug 473615] Re: cryptsetup init scripts are redundant and can break the boot

[Steve Langasek]

lvm2 is not provided by an init script, correct; this is handled via
udev rules.  This is also racy, because there's no guarantee that all
the LVM devices will be up when 'udevadm settle' ends.

"So both before and after, this is racy" - I was actually referring to
the fact that there's no guarantee *in general* that the underlying
volumes are available, either before calling /etc/init.d/rcS or before
calling /etc/init/cryptdisks-enable.conf.  In both cases, it's possible
that the volumes won't become available until after the script has run.

The difference before and after this change is that before, we get three
chances to catch the underlying volume.  After, we only have one chance.
This means we can say with a high degree of certainty that this change
will regress /for some users/.  One example where it will regress is:

 - /dev/sdh is a USB-attached disk which is slow to power up, and routinely does not register with the kernel until well after the coldplugging stage.
 - /dev/sdh1 is mounted as /home.
 - /dev/sdh2 is the PV for a luks encrypted device, which is listed in /etc/crypttab and configured to be mounted as /mnt/S3kritProj3ct.

Prior to this change, what happens is:

 - /etc/init/udevtrigger.conf finishes; /dev/sdh is not yet available.
 - /etc/init/cryptdisks-enable.conf is run (start on stopped udevtrigger).  it exits without doing anything, because /dev/sdh2 is not yet present.
 - /dev/sdh is detected; events are emitted for /dev/sdh, /dev/sdh1, and /dev/sdh2.
 - mountall mounts /dev/sdh1 as /home, and emits the "filesystems" signal
 - /etc/init/rc-sysinit.conf runs, calling /etc/init.d/rcS
 - /etc/init.d/cryptdisks-early runs, and sets up the device, resulting in new udev events being emitted
 - mountall mounts /mnt/S3kritProj3ct.

After the change, /etc/init/rc-sysinit.conf doesn't do anything
relevant, and /mnt/S3kritProj3ct is never decrypted or mounted.

The same fundamental race is still present - /dev/sdh2 becoming
available, vs. udev cold plugging finshing and /etc/init/cryptdisks-
enable.conf being called.  But there are cases where the behavior after
this change is demonstrably more likely to hit the race condition.

Now, the specific example I came up with here probably didn't work in
jaunty either, because we didn't have mountall to wait for /home to
become available before telling /etc/init.d/rcS to go.  But after all,
it's racy - and I'm pretty sure this change will make things worse for
some users (and will definitely make things better for others).

Does that clarify?

> This would mean to run all the parsing, modprobe, dmsetup mknodes, etc. code each time
> an ecrypted device gets added >(which could be on an USB key). Semantically this would
> probably be correct, since these could be handled in crypttab as well. I'm just not sure
> about how much overhead this would introduce for a running session.

As Scott has argued, users don't choose disk encryption if their
priority is boot performance.  And users can always mark devices
'noauto' in /etc/crypttab, if they don't want them autostarted - if they
*do* want them autostarted, it would be nice to do so more reliably than
we do currently.

-- 
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs