Re: LuksResume with key on partition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/07/2010 04:37 PM, Warren Crossing wrote:
> hmmm. It now works..
> 
> I seem to have miscalculated a factor of 8 somewhere, the correct size of my key was 1216bytes=9728bits
> 
> I also had to change lib/utils.c to
> 
> 483c483
> <               for(i = 0; read_horizon == 0 || i <= read_horizon; i++) {
> ---
>  >               for(i = 0; read_horizon == 0 || i < read_horizon; i++) {

This seems wrong to me. It will read one byte more than expected, why?

Do you have reproducer where it fails? If so, send me the exact commands
which fails here (including example of failing key file).

Properly set -s should work here without the patch.


> .. Now I can use the following udev rule

> DRIVERS=="usb" ACTION=="remove" SUBSYSTEM=="usb",  ENV{ID_SERIAL_SHORT}=="001D", 
> RUN+="/usr/bin/xscreensaver-command -display :0.0 -lock"
> DRIVERS=="usb" ACTION=="remove" SUBSYSTEM=="usb",  ENV{ID_SERIAL_SHORT}=="001D", 
> RUN+="/sbin/cryptsetup luksSuspend safe"

hmmm. it is interesting idea, but running such commands directly from udev
is probably not ideal (not even supported).

Luckily, Suspend/resume do not depend on udev sync, so maybe
it works in this case. But luksOpen and luksCLose can deadlock here waiting for itself)


> DRIVERS=="usb" ACTION=="add" SUBSYSTEM=="usb",  ENV{ID_SERIAL_SHORT}=="001D", 
> RUN+="/usr/bin/xscreensaver-command -display :0.0 -deactivate"
> DRIVERS=="sd" ACTION=="add" SUBSYSTEM=="block",  ENV{ID_SERIAL_SHORT}=="001D", 
> RUN+="/usr/sbin/cryptsetup luksResume safe -d /dev/%k -s 9728"

"add" event means, that new device object was added to system. But it doesn't mean
that device is ready to use - it probably will work for usb device, but
only because they send event after initialization.

(I was surprised that is is implemented that way, but it is. "add" means
you can try scan device, but it can fail and you should retry on next change event...)

IOW read of key can fail. It should react to first add or change event (only
if device is suspended). Again, maybe it works in this case, but not in other.


Anyway, I think this should be done from some widget listening on system bus
(or using libudev) not in udev rules.

Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux