Comment 6 for bug 473615

Steve Langasek [2009-11-05 13:15 -0000]:
> Does that clarify?

It does, thanks.

> > 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.

I actually meant "plug in an ecrypted USB key while the computer is
fully booted up", since the udev rules would still trigger then.

This is not a trivial problem: the cryptsetup upstart/init scripts
need a console or usplash, and are meant for the "boot" stage
(whatever that means in a fully dynamic hotplug world; but for this
purpose it means: usplash is still running or we have a console). OTOH
the devkit-disks/gvfs integration works only when we have a running X.org
session. We must make sure that udev rules don't call cryptsetup on a
console when we are in an X.org session, since this would collide. In
the best case, the script just detects that it doesn't have a console
and give up early.

Also, can udev rules even start programs which have a console, so that
this would work in the first place?

If not, this could perhaps work as a hackish mitigation for an SRU:

  ACTION=="add", SUBSYSTEM=="block", ID_FS_TYPE=="crypto_LUKS", PROGRAM="pidof usplash", RUN+="wrapper_which_runs_do_start"

This is of course not sufficient at all (you might not use usplash at
all, like on a server), but it seems to cover a safe subset of cases
where we always want the script to run; and with usplash_send we don't
need the calling program to have a console on its own.

However, this would need some care to not have usplash be stopped by
the boot (when X comes up) while the device is being set up. (I don't
know right now how to achieve this).

The longer I think about it, the more confused this seems to me :-(

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)